We should try to organize users to upvote VSCode rearchitecting issues to improve VSCodeVim performance

[jedwards1211]

@J-Fields I've felt kinda depressed about the VSCodeVim situation because as we've come to realize, it's not your fault at all, VSCode's architecture needs to be fixed to guarantee VSCodeVim responsiveness, and the maintainers really don't seem to care. I've seen Alex Dima say "we can look into separate extension hosts" but he didn't really seem sincere, they certainly haven't conceded that the status quo is unacceptable or committed to doing something about this.

Here's the main issue in VSCode: https://github.com/microsoft/vscode/issues/75627

But considering how many stars this repo has, how high Vim ranks in surveys of popular text editors, etc, and the fact that I've seen the builtin TS/JS extension bog down the extension host, I think the VSCode maintainers massively underestimate how many people are suffering from these issues. The number of upvotes on related issues I've seen in VSCode is below 100.

So, I'm thinking we should ask everyone who uses or has used VSCodeVim to lend their voice so that the maintainers will stop being apathetic about it.

What do you think? I don't know if you're willing to spam users but:

• We could crawl the stars in this repo and tag them here
• We could add a release notes to the next version bump of VSCodeVim that asks for users upvotes

I don't know if you have close contact with the VSCode maintainers, but if you haven't told them how much it sucks for you to have repeated issues like this that you can't do anything about, I'm sure they would listen to you since you're the developer of this extension and you want the best for its users.

[danielepusceddu]

Sometimes I check back on this extension to see if the performance problems have been fixed. I'd really like to use VSCodeVim, but till the performance is fixed I'll keep using vim with coc.nvim. From my experience a few months ago, this extension is simply unusable on any source code that reaches the few hundreds lines.

[jedwards1211]

FWIW I haven't seen slowness specifically on large files, but that's probably because I often disable the TS/JS built-in extension, and I think that extension is what mainly bogs down the extension host.

[jedwards1211]

@danielepusceddu from your wording it almost sounds like you think the performance issues are this extension's fault - I just wanted to check if you're aware that VSCode causes the problem by running this extension in a single thread with all others? I should add an explanation above my OP because I'm not sure if most VSCodeVim users understand this. I didn't realize it for months.

[jedwards1211]

@J-Fields the most upvoted issue in VSCode ever had 2632 upvotes, so there are more than enough Vim users that we could theoretically beat that if we raise enough awareness 💪

[J-Fields]

I'm not opposed to this idea, but I also think it places too much blame on VSCode's architecture. There's a lot that we can do to improve VSCodeVim's performance. It's been one of my focuses lately, and I'm hoping that the next version will be significantly faster. If performance is still unacceptable after we've cleaned most of the skeletons out of our closet, we can annoy the VSCode team some more 🙃

[jedwards1211]

@J-Fields I don't understand though, basically any time an extension out of your control does something time consuming, it will block VSCodeVim from responding, and there's nothing you can do about that except demand change to the VSCode architecture. Even if there are some issues with VSCodeVim itself that you fix, other extensions (including the JS/TS language features builtin extension, in my experience) will continue to cause problems for it. All of the competing Vim extensions are unable to respond when something else is tying up the extension host.

[jedwards1211]

what performance problems are actually VSCodeVim's fault anyway?

[jedwards1211]

Another way to look at this is other extensions doing work on the same thread as VSCodeVim handles keyboard input on (or other type command extensions), is just as bad as doing work on the UI thread, which Alex Dima himself said they sought to avoid by making the extension host, ironically.

I think VSCode's architecture fully deserves a large amount of blame for this.

[J-Fields]

Yeah, to be clear, I totally agree - extensions which hijack the type command shouldn't be on the same thread as other extensions. Perhaps I'm biased because I don't use any particularly resource-hungry extensions, and the codebases I work in aren't generally large enough for the language client to be a big issue either, so the lag I experience is mostly from VSCodeVim itself.

For now, I'm not willing to spam users, but I can create & pin an issue explaining the problem and direct users to go upvote the VSCode issue.

[J-Fields]

what performance problems are actually VSCodeVim's fault anyway?

Off the top of my head, the main culprits are:

• Keeping track of our own undo stack, which requires retrieving and diffing the entire file's contents pretty often (this has been improved recently, but is still a problem)
• Replaying changes one character at a time (this is improved on master, but it's not yet a perfect solution)
• Naively recalculating search results far too often (I'm working on improving this now)

Basically, the fact that VSCodeVim slows to a crawl on large files is our fault. The fact that it makes the editing experience reliant on all the other active extensions being performant is VSCode's.

[ronakg]

• Keeping track of our own undo stack, which requires retrieving and diffing the entire file's contents pretty often (this has been improved recently, but is still a problem)

If u and <C-r> are mapped to VSCode's native undo and redo, is extension's undo stack mechanism disabled?

[J-Fields]

If u and <C-r> are mapped to VSCode's native undo and redo, is extension's undo stack mechanism disabled?

Nope

[danielo515]

Performance is a lot better recently or it is just my impression?

[J-Fields]

@danielo515 I put some serious effort a little while back into improving performance. There's definitely still more that could be done, but I'm glad you've noticed a difference!

[danielo515]

Thanks for your efforts @J-Fields ! they made my editor way more usable. There are still problems with perceived slowness because sometimes you don't see the result of your commands. Like when you want to surround something, you hit yst (for a tag) and nothing happens, then you type the surrounds and it works, but the feeling is that it is slow because you don't see any change on your screen (or, if there is any, it is too hard to spot)

[J-Fields]

@danielo515 I very rarely use surround, what sort of visual feedback are you expecting? The operator-in-progress cursor will be there in the next release - is there anything else?

[danielo515]

@danielo515 I very rarely use surround, what sort of visual feedback are you expecting? The operator-in-progress cursor will be there in the next release - is there anything else?

Any command that requires you to look at the bottom bar has this feeling. Some commands appear centered on the bottom bar while others appear shifted to the right, and it takes a second or two to find it in the absolute mess the bottom bar is. It will be better to have a pop-up or some kind of inline visual feedback, but I'm not sure if vscode allows such thing

[maxnordlund]

I've been using VS Code with this extension for a couple of years now and I haven't really experienced any slowdown, except for . with many multiple cursors. The latter is true in Neovim as well, since the multiple cursor plugin there also has to work around the base editor, although in very different ways.

I agree that the architecture could be better, like using different isolate for different extensions which prevents one extension from messing up JS globals, and permits running them in separate threads. But as with all architectural changes, this is going to get big, fast, and I understand why the VS Code team is hesitate to do it and regress.

Still, upvoting and making the VS Code team aware of the many Vim users is a good thing. If nothing else that may make them listen to you @J-Fields when you do need them to make a change.

[jedwards1211]

@maxnordlund

I haven't really experienced any slowdown

do you use TypeScript though? That's where the majority of problems come from for me, for example when I type an opening < for type parameters it will sometimes cause a slowdown. Part of the problem here is not everyone experiences this

[maxnordlund]

Not really no. It's Erlang these days, and Python before. I do write some JavaScript but not TypeScript if that makes a difference.

[berknam]

for example when I type an opening < for type parameters it will sometimes cause a slowdown. Part of the problem here is not everyone experiences this

@jedwards1211 That might be related to an issue that has been fixed in PR #5287 and should be out on the next version.

[jedwards1211]

@berknam sure, but remember, they could accidentally break performance again at any time

[J-Fields]

@berknam sure, but remember, they could accidentally break performance again at any time

Gotta keep you on your toes 😉

There actually has been progress on the core problem of a single-threaded extension host - the option of running extensions in web workers was being worked on. Not sure where that stands at the moment; I'll have to look into it.

[jedwards1211]

Oh btw, I thought @berknam was talking about a PR fix in VSCode itself. I don't believe the issue with < I saw was VSCode's fault; Along with performance problems in the extension host, I noticed the contents of the outline sidebar section disappearing the a moment after I typed a <, and I assume the TS/JS tools generate the contents for the outline.

[J-Fields]

If you have any insert mode keybindings that start with <leader> or a control character like <C-d>, it's likely #5287. The next version will be released soon (today, I think) - let me know if the problem persists after that's released, and I can dig into it deeper. I write typescript pretty often and have no performance issues.

[jedwards1211]

I haven't had much performance problems lately tbh, it just drives me nuts that there's no solid solution to guarantee nothing can mess with keyboard input. But then again I haven't worked with aws-sdk typescript defs lately, which are really big and have caused performance problems before. I've been trying to switch to WebStorm but I can never find the time to port my own extensions to WebStorm...

[askfiy]

So far, there are still performance issues. I have tried it on Linux, Windows, and Mac, which is really frustrating.

[macintacos]

Anyone on Insiders right now that can confirm/deny that this helps?

[Mrcuve0]

I can confirm it works perfectly on my side, VSCode 1.70.0 stable

[nightire]

Anyone on Insiders right now that can confirm/deny that this helps?

Nice! It works great.