Vim plugin slows vscode down.

[Kesanov]

If I turn vim plugin on (all other plugins off), vscode starts to lag. There is a noticeable delay (0.1 sec) on every keyboard input.

[theprash]

I have noticed this lag too. It's subtle but definitely noticeable compared to plain vim, and even compared to the Visual Studio vim plugin. Some more info:

• The lag is there even with a new plain text file and no open project.
• Only the editor lags: Typing in the command palette feels fine. Not surprising.
• The lag seems to be on all actions: insert mode edits, normal mode edits, cursor movements. For me it's actually most noticeable for me on cursor movements as I often scan forward with multiple taps of w and go one word too far.

This is on Windows. It's possible this is a platform specific thing so it's worth mentioning.

[theprash]

I've just tested this on a colleague's macbook and I think the lag is present there too.

[theprash]

I've noticed that things become much more snappy when you make the window very small, which suggests that the problem is rendering time.

I also discovered a method that may expose this more easily: Type 100aa<Esc> to insert a 100 times.

Small window:

Maximised (2048x1152 with 125% scaling):

[movsb]

I can type only one character per 2 seconds after I enabled vim. What happened?

[kennym]

Any fixes?

[Chillee]

@theprash That example is a little bit different. What people typically seem to mean about "lag" is latency, that's throughput.

I'm not sure what would cause such extreme latency. I'll do some performance profiling this weekend. Maybe the main causes of slowdown are just accentuated for some users.

[jpoon]

I haven't quantified any of these suspicions but possible areas of improvement:

• Every time a key is pressed, it goes through every possible action and tests whether it is applicable (https://github.com/VSCodeVim/Vim/blob/master/src/actions/base.ts#L193), we can quickly limit the amount of actions to check by building a dictionary/trie on @RegisterAction decorator.
• I think we update the screen way too often. Whenever I walkthrough and debug the extension, it always seems like https://github.com/VSCodeVim/Vim/blob/master/src/mode/modeHandler.ts#L1139 is called multiple times.

[johnfn]

Definitely profile before chasing down any potential problems. I am 95% certain the problem lies in us doing updateView more than we have to. Problem is that even a single call to updateView is expensive and I don't believe there's a way to do VSCodeVim without calling it at least once :P

[Chillee]

So one major source of performance issues is caused by interacting with the system clipboard (I'm guessing that might be why Windows users seem to complain more about this?). It's at least a quarter of the time needed on my computer right now.

This issue is accentuated by us making multiple calls to the Register object for a command like p.

Could anybody getting immense performance issues try setting useSystemClipboard: false and seeing if they go away?

[Chillee]

@johnfn @jpoon Also as an update, I don't think updateView is the main cause of the issues people are talking about. For "elementary" actions like p, it only gets called once, and it takes up a very small proportion of the time (typically <5ms).

The majority of the time is spent in await action.execCount.

[saites]

Is there any movement on this? VSCode with VSCodeVIM and vscode-go is unusably slow for me. I notice it's worse in _test.go files. Disabling either extension returns to a snappy performance, but the two together appear incompatible.

[armoucar]

Could anybody getting immense performance issues try setting useSystemClipboard: false and seeing if they go away?

Definitely this for me. I was unusable until I set this to false. And as you vimmers know, without this option life is very sad.

[saites]

Definitely this for me. I was unusable until I set this to false.

@armoucar: My User Settings show that false is the default value. Is that not the case for you? I tried explicitly setting it to false in my personal settings, but didn't see a difference.