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.

[xy137]

tried all the solutions here and still have issues with large files on macos and windows, usually using typescript.

seems like theres no real fix to this and we just have to deal with it?

fwiw, the lag does seem to reduce when having less extensions, but i need extensions :)

[takas3]

I had the same problem in a 5k line file.
But Disabling the extension "Bracket Pairs Colorizer" solved the problem.

[st-schneider]

I uninstalled those long time ago and still had the impact.

[chasingmaxwell]

I was troubleshooting this issue today and came across the neovim extension. So far it meets my needs well and doesn't have any of the same performance problems. I've used and loved this extension for a long time, but the performance issues have become intolerable. In case it helps someone else, here's the extension I'm using now: https://github.com/asvetliakov/vscode-neovim

[jensbodal]

I'm trying out the neovim plugin now.

Note that the extension requires neovim being installed, and configuring it is a lot different than the vscode extension. I don't want to derail this issue on vim vs neovim, but vscode vim has become extremely problematic for large projects.

[st-schneider]

I even took a way different road and switched to https://marketplace.visualstudio.com/items?itemName=gregoire.dance which is mainly the kakoune keymap

[adriaangraas]

Observation: for me it helped to add some metal to the stack. After installing a dedicated GPU, the sluggishness of this plug-in disappeared in total. The problem is not a general one though: before installing the GPU, VSCode would be barely usable with VSCodeVim but fast otherwise, regardless of the VSCode hardware acceleration setting.

[skplunkerin]

For me it seems like the longer VSCode is open, the worse/slower/laggier it gets. I think for me it's tied to the VSCodeVim clipboard? (the main thing that gets sluggish for me is whenever I'm yanking/pasting. I don't know what the setting useSystemClipboard does (sounds related), I haven't played with that, it's set to false for me. I'm on a Mac)

This likely isn't the main issue here but might be related to it. My hack/workaround is not a solution, but it might help others.

If I run Developer: Reload Window in the Command Palette, I'll be good again for an hour or two before the sluggishness makes it unusable again. It's horrible I need to run that command so often 😞

[ghost]

In my case, I changed "Render Whitespace" from "none" to "selection", changed "Cursor Style" from "Block" to "line", and changed "Cursor Smooth Cart Animation" from "true" to "false". By changing the setting like this, it is not perfect, but it is solved by slowing down.

[jensbodal]

In my case, I changed "Render Whitespace" from "none" to "selection", changed "Cursor Style" from "Block" to "line", and changed "Cursor Smooth Cart Animation" from "true" to "false". By changing the setting like this, it is not perfect, but it is solved by slowing down.

I'm getting desperate so I'll try anything. Neovim didn't work out, I had everything setup but had way too many issues with undo/redo and going from insert to normal mode.

Your settings for anyone interested:

    "editor.renderWhitespace": "selection",
    "editor.cursorStyle": "line",
    "editor.cursorSmoothCaretAnimation": false

I feel like I'm just throwing paint at the wall at this point

[J-Fields]

@jensbodal What extensions do you have installed? They are by far the most impactful factor.

[hiro0604-0120]

Introduction.

I use a translation tool because I don't speak English.

I'm sorry if the English is awkward.

I was trying to find out more about this issue, and I found something surprising.

In my case, I only suffered from this problem when I used vscodevim on my laptop (OS:win10).

When I connected HHKB which my friend gave me as a present by bluetooth today, the problem did not occur even though I did not change anything in the setting.

I usually use autohotkey and set up the cursor keys to do vim-like operations.

When using HHKB, fn+hjkl is set to replace the cursor keys in the HHKB body. (The cursor keys are actually being typed.)

In other words, when the cursor keys are used, no delay occurs, but I think that the phenomenon of delay occurs when various tools are used to simulate the cursor keys.

I'm testing it in a variety of environments and will report back with the results.

[ghost]

Since this expansion program was updated yesterday, there has been a tremendous increase in speed in my work environment. I usually vs code to work with the "wsl". My Thinkpad T420s laptop also uses setting sync, so it's the same VS Code environment, but there's no slow down in T420s. The operating system of the T420s is CentOS 8. Maybe the speed problem of WSL1 is the root cause?

[deepDinosaur]

If you use Dart extension : Dart-Code/Dart-Code#2902

... which is caused by some extensions (like Vim) having to send keypresses through the extension host, where they fight for a single thread with all other extensions (see microsoft/vscode#75627).

Enabling the LSP preview (the dart.previewLsp setting) should significantly improve

It works for me.

[stevenossa21]

I was troubleshooting this issue today and came across the neovim extension. So far it meets my needs well and doesn't have any of the same performance problems. I've used and loved this extension for a long time, but the performance issues have become intolerable. In case it helps someone else, here's the extension I'm using now: https://github.com/asvetliakov/vscode-neovim

It works fine, thanks!

[yuchen16]

It seems that the problem was caused by the "problem bar", after I uncheck "Vim (Extension)" , typing became smoothly

[reinux]

It seems that the problem was caused by the "problem bar

This improved it by quite a bit. Still not as fast as I'd like it to be, but it's only slightly slower than with all extensions turned off, so the rest is a vscode problem.

[J-Fields]

If you're having performance issues with all other extensions disabled, I'd be curious about:

• What kind of file (e.g. typescript)
• How big that file is
• How big the rest of the project is

There are still ways we can be more efficient, but I think it's improved a lot gradually over the last handful of months.

[reinux]

It's definitely faster than it was before. I remember it being nigh unusable at one point on certain projects, so I had to go back to Visual Studio.

The code's in typescript, typically about 200-300 lines long. No super long strings or anything like that. The project is a fairly big Angular project -- probably a couple hundred files in just our code.

I'd imagine the project size shouldn't have much of an effect outside of when autocomplete's invoked, though, right? Especially with the language service and all that turned off.

[J-Fields]

Yeah the project size should mainly come play for autocomplete, though also for colorization, etc.

[reveriel]

• Disabling the extension "Bracket Pairs Colorizer"
• remove the "escape" "escape" keyboard shortcut for exiting the Zen mode
  fix the problem

[PeterAaser]

I just swapped keyboards with a coworker before finally realizing that the vim plugin caused this.
I think there are two things at play here, the first is the performance issue, the second is the fact that it is possible for a keystroke to get dropped without a warning being sounded off. I would expect that a dropped keystroke should create a small error dialog to warn me! Does vscode have support for this? It would make sense, because if not every plugin causing problems will implicitly be blamed on vscode itself rather than whatever plugin causes it, making it both hard to track down issues and making vscode look bad when it's not at fault.

[markonius]

Is #4101 possibly related? Maybe something else that should be asynchronous has become synchronous?

[Mrcuve0]

Hi, just started using the plugin and immediately stumbled upon the issue on a 140 line long C source file, having the built-in bracket pair colorizer and various "too-essential-to-disable" plugins.

Take a look at the solution proposed here: microsoft/vscode#75627 (comment)
As the time of wiriting it is available as an experimental feature even on the stable release of VSCode, no need for the insider version. Also, no need to disable other plugins.
It completely solved all my problems (I had lag even with Neovim and other plugins).

[tfriedel]

the solution in the last comment didn't solve it for me unfortunately

[yamanidev]

Unbelievable that this issue still persists to this day.

[AnoMorCH]

I had the same issue. My current version of the plugin is v1.25.2. To solve the problem, I did the following:

1. Opened settings.json using Ctrl+Shift+P
2. Deleted everything which was inside

In my case, this definitely was because some of my installed VS code plugins were in conflict with the Vim plugin. But I was too lazy to find which was the one so I just got rid of everything :D.

[jorgemmsilva]

after trying to deal with this issue a few years ago, I just switched to amVim and never looked back (it's not so feature-rich, but it works for me).
leaving this as a suggestion for whoever is experiencing the lag

[zachbroad]

What improved it for me...

Disabling indent guides
Disabling relative line numbers

Those helped the most but I also disabled statusBarColorControl