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.

[armoucar]

Sorry @saites, I was wrong there. My performance problem happens when this flag is set to true, only on Windows.

[jpoon]

Very interesting -- are you both on Windows @armoucar @saites ?

[saites]

are you both on Windows

@jpoon I am on Windows

To follow-up on setting useSystemClipboard, I don't find a discernable performance difference regardless of its setting.

More observations:

• Even with both extensions enabled, I have not noticed issues with editing other types of files, which isn't terribly surprising.
• It seems much worse for _test.go files than it is for non-test .go files
• Typing slowly is fine; inserting a single letter appears instant
• Typing hangs very badly for multiple characters, then "catches" up to suddenly insert others
• When it's very bad, I have to wait for the buffer to complete writing characters before I can use esc
• Other operations (navigation, highlighting (visual mode), yank, put, delete, and switching to insert mode) are plenty snappy and don't appear affected by this

[armoucar]

@jpoon I use the plugin on Mac (at work) and Windows (at home, but not that much).

Doing a little bit of test now on Windows, vim operations that would send to clipboard (when vim.useSystemClipboard: true) are really slow: d, c, x, dd, yy.

I have no issues when on a OS X

[Chillee]

I think there's a couple causes of massive lag. The first is the system clipboard library we use. Another one is interactions with other extensions, especially extensions that do a lot of work.

One design deficiency imo of the current extension system is that all the extensions run on one thread :/

[BWoodfork]

Having really bad lag issues on OSX as well

[vxio]

I found a workaround:

The delay on the keyboard input is gone if you turn on Zen Mode.

And I use the following lines in my User Settings:

  "zenMode.hideStatusBar": false,
  "zenMode.hideActivityBar": false,
  "zenMode.hideTabs": false,
  "zenMode.restore": true,

[dyxushuai]

@xiao-vincent No help, still lag for me.

[Diadlo]

I'm not sure, but seems redo and undo actions quite fast. I think it's possible to take part of implementation of this actions to make others. Is it possible? For example hack like this: create fake action and redo it.

[acicovic]

I notice too this delay. I don't know if this is of any use, but in my case:

• Hiding the sidebar improves performance
• Adding relative line numbering hinders performance
• Enabling or disabling easymotion does not seem to have any effect on performance

I've done those tests by holding the j or k keys down, in smaller and bigger files.

[Peluko]

I've been suffering this, to the point of thinking about returning to Spacemacs, but finally it improved by setting "vim.statusBarColorControl": false,. Disabling color change has improved editing performance a lot. I still can notice some lag, but it's mostly usable.

[acicovic]

@Peluko According to the documentation this feature is set to off by default. Did you have it enabled?

[Peluko]

@acicovic I enabled it on purpose some weeks ago, but at the moment I switched from working on Windows to working on macOS, so I didn't relate this to the lag.

[jrwrigh]

For my case insert mode is fine, most jumps are relatively snappy, but line movements are awful on my laptop. I press j and can see the cursor move down a line, move back up one line, then move back down again. If I press it multiple times, it does the same routine. If I press and hold, when I let go it'll still be moving as it's trying to catch up. It's at the unusable point for me. Time to learn how to transfer my extensions and settings onto real Vim....

[acicovic]

In addition to my previous comment, VSCodes newest feature "Highlighted indent guides" further worsens the situation as it degrades Vim's performance.

[Peluko]

@u2berggeist more or less the same here. By disabling statusBarColorControl it performs better, almost usable but annoying.

[J1marotta]

Has anyone found a solve for this? I'm using a 2013 macbook pro with 8gigs of Ram, and running zero other extensions or user settings, Still get terrible performance. with vsCodeVim

can hold J and then watch the editor catch up as It scrolls