The VSCodeVim extension has very bad performance in GitPod

[andypea]

Describe the bug

The VSCodeVim extension provides a vim-like interface for Visual Studio Code.
When this extension is installed on GitPod the editor runs painfully slowly.

Steps to reproduce

Install the VSCodeVim extension on GitPod and try to edit a file.

Expected behavior

A usable editor with vim-like interface.

Additional Information

I'm in New Zealand and I'm using the free plan, so that may be contributing to the problem.

[JesterOrNot]

@akosyakov can you look at this?

[Kreyren]

Same issue on my end.

There is significant delay in between actions and seems to cause instability. (GUI sometimes break while using this extension on gipod)

[Kreyren]

FWIW emacs extension seems to have same issue

[JesterOrNot]

See eclipse-theia/theia#5125

[andypea]

When the VSCodeVim extension is installed the editor still remains painfully slow even if I set the Vim::disableExtension option to true. Uninstalling the extension immediately returns the editor to full speed.

I've also tried editing files in an actual copy of Vim opened within the terminal. This is still a little slow, but it performs much better than the Theia editor with VSCodeVim enabled, so I think the issue isn't caused by the latency between me and the GitPod container.

[andypea]

I just checked and this problem also exists when using Eclipse Che containers hosted on OpenShift. If you have an OpenShift login you can see an example here:

https://github.com/andypea/openshift-test

[akosyakov]

It is an issue how Vim extension is designed, it intercepts each editor keystore and process it to decide what to do: VSCodeVim/Vim#2021 So whenever you press something it is delivered to backend, processed and then sent back. It is slow in local VS Code, obviously slower for us because of latency. The worst about this extension that it affects performance of other extensions: microsoft/vscode#75627

[jedwards1211]

@akosyakov it's kind of the reverse, other extensions can severely affect VSCodeVim's responsiveness

[dclong]

Keys are constantly ignore. The extension is barely usable.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[davidar]

This is still an issue. I wouldn't mind the lag if not for the fact that it even affects insert mode. Some kind of local echo (like the terminal seems to have?) would be an improvement.

[jedwards1211]

Navigating around with vi keys is just as painful as insert mode when the extension host is bogged down

[jedwards1211]

UI responsiveness is so sacred that...not even keyboard extensions are allowed to interfere with it, apparently 🙄. But builtin keyboard input somehow gets a pass, and is allowed to run on the UI thread.

[jankeromnes]

Hi @andypea, @davidar, @jedwards1211 -- sorry for the over-eager stale-bot here. 😬

Does this problem still happen if you switch your Gitpod IDE to Code in https://gitpod.io/settings/ ? (Actual VS Code is available as an IDE option under "Feature Preview", and will soon become the default IDE in Gitpod)

[jedwards1211]

@akosyakov re-reading your comment, I do agree that it's bad to pass every single keystroke back and forth to a separate process using IPC or however gitpod does it. But this is the fault of VSCode's architecture, it doesn't allow any extensions to run in the main process, and there's nothing any Vim extension can do about that (except one that unbinds from the type command in input mode, so that keyboard input goes through VSCode's main process. But non-input mode Vim commands can still be just as slow). Isolation is more important to them than keyboard input latency.

I've seen rumors that they might one day try to run extensions in worker threads, which would be a massive improvement. I don't think worker threads were available in V8 when they started writing VSCode, so it had significant negative consequences for the architecture.

[davidar]

Does this problem still happen if you switch your Gitpod IDE to Code in https://gitpod.io/settings/ ?

[akosyakov]

In VS Code Vim extension will run in the web worker and it should improve performance a lot. The issue is it right now that Open VSX does not index web extensions properly yet (to be fair it is not even official VS Code feature yet): #3259 As soon as it resolved you can switch to VS Code, install Vim extension and enjoy it without performance degradation.

[jedwards1211]

Will all extensions be run in the same web worker? It will certainly perform better than running them in the backend, but if they're sharing the same worker thread other extensions will still be able to hamper Vim performance like they do in desktop VSCode.

[akosyakov]

It is up to an extension to decide, they will need to specify that web is a supported extension kind in package.json as well as browser entry point for code which can be executed in the web worker. As for now I don't expect that many extensions can satisfy second requirement, probably on Vim.

[jedwards1211]

But will all browser extensions run in the same web worker, or will they all have their own individual web workers?

[delucca]

In VS Code Vim extension will run in the web worker and it should improve performance a lot. The issue is it right now that Open VSX does not index web extensions properly yet (to be fair it is not even official VS Code feature yet): #3259 As soon as it resolved you can switch to VS Code, install Vim extension and enjoy it without performance degradation.

That is strange.

I've enabled the feature preview, switched to Code as my default editor and was able to install the Vim extension.

But, after installing it, there is a HUGE delay between key press and something happening in the editor.

[akosyakov]

But will all browser extensions run in the same web worker, or will they all have their own individual web workers?

I think yes. We will see how it works when there are other web extensions. I don't expect heavy extensions like TypeScriprt or Java smartness to run there they need fast access to underlying runtimes and fs.

That is strange.

#3259 is not resolved yet. Until then it should not be possible to install this extension at all in VS Code, that you were able is strange. We are talking about this extension right: https://open-vsx.org/extension/vscodevim/vim ?

[delucca]

But will all browser extensions run in the same web worker, or will they all have their own individual web workers?

I think yes. We will see how it works when there are other web extensions. I don't expect heavy extensions like TypeScriprt or Java smartness to run there they need fast access to underlying runtimes and fs.

That is strange.

#3259 is not resolved yet. Until then it should not be possible to install this extension at all in VS Code, that you were able is strange. We are talking about this extension right: https://open-vsx.org/extension/vscodevim/vim ?

My bad.

Actually I've activated the Code feature preview and when I went back to my code editor it was using Theia instead (it took some time for it to update). So, I've actually installed it in Theia at first.

Now that I've tried in the Code editor, I was not able to install (as expected according to this issue).

Looking forward for a solution to this :)

[akosyakov]

You can install VSCode VIM extension from Open VSX. And it runs alone in browser web worker.