Vscode-neovim: Recommend to all users of this extension to upvote the perf issue in VSCode

[jedwards1211]

Hey @asvetliakov, I hope your family is doing okay in this tough time.

I've seen you in https://github.com/microsoft/vscode/issues/75627, you might recognize me as one of the angriest commenters there 😜

I really appreciate your efforts in making this extension, but still hope to see the VSCode architecture fixed because of this extension's inherent limitations (and the fact that commands outside of insert mode can obviously still get blocked).

After feeling like trying to talk sense into the maintainers is hopeless, I've been thinking we need grassroots organization -- getting as many upvotes on that issue is possible. There are 745 stars on this extension right now, yet only 51 upvotes on that issue. And 7200 stars on VSCodeVim -- imagine if we could get several thousand upvotes on that issue! I think then the maintainers would realize whether they like it or not, the architecture is hurting a lot of users. The most upvoted VSCode issue only had 2632 upvotes -- so there are enough Vim users that we could theoretically beat that!

The biggest problem is that most people probably don't realize the performance problems are caused by VSCode architecture. Even then, it can be hard to find that VSCode issue. We need to raise awareness of it so that everyone upvotes it. I propose things like:

• Pin an issue that explains the performance problems and asks people to upvote that issue
• Also point it out in the README?
• Maybe even add a big banner to release notes that pop up when this extension is updated pointing out the issue.
• Most nuclear option, but maybe too spammy, tag everyone who's starred this repo in the explainer issue.

I've filed a similar issue on VSCodeVim though Jason Fields seems oddly silent about it despite categorizing the issue.

[amanpalariya]

Why are Vim and Emacs still provided in form of extensions?

Many online editors(for example the editor of Codepen, Codechef, Hackerrank) give normal, vim and emacs type editors equal priority and allow us to easily toggle this setting.

But, sadly, this isn't the case with most IDEs.

[jedwards1211]

@amanpalariya I think that's more a consequence of the fact that those editors didn't want to go to the trouble to make a plugin API and plugin marketplace. But a few IDEs do have built-in keys (It seems like a built-in Emacs option is more common, I imagine because Emacs is easier to emulate)

[justinmk]

Why are you so sure that the vscode architecture is wrong? https://github.com/microsoft/vscode/issues/75627#issuecomment-519125065 is a reasonable answer. VSCode warns about slow extensions, which is a huge improvement compared to, say, Vimscript...

Extensions that are doing expensive things could/should start child processes to do that work (perhaps node.js or vscode needs an ergonomic multiproc API to help with this). Someone in that thread mentioned https://github.com/josdejong/workerpool .

[jedwards1211]

@justinmk it's inevitable that from time to time extension authors will make mistakes that cause their extensions to hog the extension host. I have seen the builtin TS/JS tools do this at times.

You really want Vim extensions to be laggy any time that happens? (Until a fix to the offending extension is released potentially days later?). Because the current arch guarantees it will be laggy when that happens.

If a Vim extension its own separate thread or process it would always be responsive, even when other extensions are hogging the main extension thread.

[justinmk]

I don't want anything to be laggy :) I don't use many vscode plugins so maybe that's why I don't notice the issue. But there are significant tradeoffs, mentioned in the other thread:

running each extension in its own separate thread has implications such as: text buffer memory duplication or a variant of a text buffer written in C++ that can be snapshotted and shared safely across threads, native node modules loaded by extensions in the ext host which are not multi-process aware, or sync API dependencies between extensions

Were there replies that addressed these tradeoffs?

It also makes plugins harder to author, thus one may get "performance" but perhaps many more bugs--and less integration between plugins. See also https://raphlinus.github.io/xi/2020/06/27/xi-retrospective.html

[jedwards1211]

@justinmk Since you haven't suffered this problem, it's hard for you to sympathize. If the app became unresponsive to keyboard for several seconds every time you type a < for type parameters, or at other random times, you would probably agree that the project needs to make whatever changes necessary to solve the problem, whether it means making a threadsafe text buffer implementation or whatever.

Other people have pointed this out in that thread. Non-Vi users are even less able to sympathize because normal keyboard input runs in the UI process, and can't be slowed down by extensions. As others have said, if normal keyboard input had lag as bad as some of us have dealt with using Vi extensions, the VSCode core team would have moved heaven and earth to fix it.

On that subject, @asvetliakov's main motivation for this extension AFAIK was to unbind from the type command during insert mode so that at least then what you type goes through the UI process and can't get blocked by extensions. (Commands outside of insert mode can still get blocked though.) Imagine dealing with input lag so bad you actually get the motivation to make a whole new Vi extension...

Sometimes tradeoffs are computationally inherent, but in cases like this, a better overall architecture is completely possible, but the project just didn't go down that road because because of the short-term pressures and technical limitations they were up against early on. And those early decisions can become an albatross that holds a project back if devs always surrender to the implications of major changes instead of solving them. Most complex software projects hit a wall like this.

I think VSCode was at a disadvantage compared to other IDEs because JS in the early days didn't have workers and still doesn't have the kind of shared memory between threads that C++/Java do. And that's why I think Java IDEs I've used like Eclipse and WebStorm don't seem to have this problem. I'm sure it's because they have concurrency that enables their Vi extensions to run in a separate thread from long-running background processes, because it was easier for them to use a concurrent architecture from day one.

I finally gave up and switched back to WebStorm despite some things that annoy me about it, and despite having developed a half-dozen VSCode extensions to ease my development process. If VSCode doesn't solve these issues, someone will eventually make a better JS IDE.

[jedwards1211]

As a more direct answer about those implications, a thread-safe text buffer is not a show-stopper, it's just work, and doesn't sound necessary anyway if this is solved by allowing text command extensions to run in a separate extension host process (rather than another thread in the UI process). As far as native modules and sync API dependencies between extensions, I don't think anyone asking to run text command extensions in a separate thread/process needs that so it wouldn't have to be supported by the solution. I think some people were proposing running every extension in its own extension host, but (as discussed later in that thread) it would be sufficient for solving the keyboard lag just to run text command extensions in a separate host.

[asvetliakov]

I actually understand vscode devs here - changing core architecture of something big as vscode is very costly both in $ and time, prone to errors and will introduce a ton of regressions. Nobody will be doing that. That's not similar to adding file icons to explorer, which was another issue barking by community, and it took a year-ish to implement it.

So we got what we have got.

someone will eventually make a better JS IDE.

There is VIM-based IDE in development if you don't know already, onivim2

[jedwards1211]

@asvetliakov sweet, I'll check that out!

[jedwards1211]

I just realized, the VS in VSCode stands for Very Slow lol

[asvetliakov]

@jedwards1211
You haven't tried to make vscode-like ide from emacs lol

For vscode, I'd say it's pretty ok, just need to be careful what extensions are you installing if you're using any vim extension 🤣 . Things like bracket colorizers are no way here.

[jedwards1211]

@asvetliakov like even with all extensions disabled that I would expect to do background work the VSCodeVim keyboard lag gets worse over time and I have to refresh the window.

This includes the builtin TS/JS tools disabled (they have definitely tied up the extension host before) so it's barely even an IDE at that point except for various codemod commands I created.

And even aside from this issue, the completions menu is hella slow compared to other IDEs I've used (Eclipse, WebStorm, Visual Studio, Qt Creator). It's not on par with what one would expect from Microsoft.

I'm slowly trying to switch to WebStorm, though I haven't ported any of my codemod command extensions over to it yet. WebStorm has great performance, the only annoying thing about it is there are a lot of pesky hassles when trying to work on multiple node packages in a single workspace.

[justinmk]

If you think WebStorm has great performance then this is a confusing discussion. Mostly a reminder that different users perceive performance differently.

Building extensions for JetBrains products also is quite a chore, which has its own implications...

[jedwards1211]

Yeah I haven't looked into building extensions for WebStorm yet but I wouldn't be surprised if it's disappointing, because making extensions for VSCode was easy.

Do you still use it or did you quit using it years ago?

Several years ago WebStorm had bad performance and I got tired of it. But since I've started using again it a month ago I haven't experienced any keyboard lag or freezes, and its intellisense and jump to symbol respond way faster than VSCode does for me. Maybe hardware differences can cause wildly varying results, but it doesn't seem like I could be subjectively misperceiving things.

Also if you use vscode-neovim that's one reason our experiences are different because I still use VSCodeVim, which has lag even in insert mode (whereas vscode-neovim unbinds from the type command in insert mode).

The builtin TS/JS tools choke on large APIs like aws-sdk and not everyone uses APIs like that. My hunch is that since the main VSCode process is single threaded and deserializing extensions' completion lists has to happen on the main process, large completion lists inevitably block the UI, whereas in WebStorm completion lists can be built on a background thread and then just passed by reference to the UI thread. As the author of https://github.com/microsoft/vscode/issues/75627 stated, his extension provides completions and he had to put a lot of effort into preventing performance issues, but he was still running into walls.