Vim gets very slow, the longer VSCode seems to be open

[RononDex]

Describe the bug
Since a few days / weeks vim has become incredibly slow for me, and it gets worse the longer vscode is open. Any mode change takes around 1s when vscode is open for 1h or so, and around 2s when its open 2h or so.
This also includes using easymotion

To Reproduce
Steps to reproduce the behavior:

1. Keep vscode open for some time (and do some work)
2. vim gets slower and slower as time progresses
3. restart of vscode makes it fast again

Expected behavior
Performance does not degrade with time

Environment (please complete the following information):

Extension version: 1.9.0
VS Code version: Code 1.36.1 (2213894ea0415ee8c85c5eea0d0ff81ecc191529, 2019-07-08T22:59:35.033Z)
OS version: Windows_NT x64 10.0.16299

System Info

Item	Value
CPUs	Intel(R) Core(TM) i7-8700K CPU @ 3.70GHz (12 x 3696)
GPU Status	2d_canvas: enabled flash_3d: enabled flash_stage3d: enabled flash_stage3d_baseline: enabled gpu_compositing: enabled multiple_raster_threads: enabled_on native_gpu_memory_buffers: disabled_software oop_rasterization: disabled_off protected_video_decode: enabled rasterization: enabled skia_deferred_display_list: disabled_off skia_renderer: disabled_off surface_synchronization: enabled_on video_decode: enabled viz_display_compositor: disabled_off webgl: enabled webgl2: enabled
Load (avg)	undefined
Memory (System)	31.87GB (11.71GB free)
Process Argv
Screen Reader	no
VM	0%

[RononDex]

UPDATE:
I figured out what causes it to get slow.
If I disable "vim.statusBarColorControl": false,, it gets fast again

So updating the status bar is what takes so long

[ctrl-alt-adrian]

I'm still having this issue.

"vim.statusBarColorControl" isn't enabled for me and it's lagging.

[renodubois]

Also getting a similar issue (really bad lag in INSERT mode, doesn't really have any rhyme or reason to it) and I also have vim.statusBarColorControl disables. Also doesn't get fixed on restart, still seems to persist.

[danditomaso]

I'm having this issue as well, and i dont have vim.statusBarColorControl enabled. So i'm hoping to see a fix to this soon, primarily while switching from normal to insert mode can take up to a minute switching modes.

[ctrl-alt-adrian]

I'm having this issue as well, and i dont have vim.statusBarColorControl enabled. So i'm hoping to see a fix to this soon, primarily while switching from normal to insert mode can take up to a minute switching modes.

Yeah. I notice the typing slows down a lot. Its like it's in a bottleneck and I have to wait for Vim to catch up to what I typed.

[renodubois]

Wanted to bump and see if anyone had found a fix for this - it's caused me to disable the Vim extension a few times now, since switching between insert and normal mode takes so long.

[stevenguh]

I haven't actually had Vim Code Vim slow down over time, but I have it slow down when I open a large file.
If you are seeing slow down on vim operations, maybe try using the profiling tool in the Developer tools and figure out what causes it?

[sebastianhoitz]

I'm seeing a similar issue. For me, when I press J or K for like a second the cursor afterwards is still catching up while in normal mode.

This is especially bad if the explorer sidebar is open. If I hide it, the performance gets better.
I have tried disabling the statusBarColorControl, but this did not change anything.

[contang0]

Same issue. Currently the plugin is unusable for me.

[jakechiam]

Yea, my vim plugin has running really slow, for the past few versions of vscode.
Curiously though, I have no problems with the vim plugin when using vscode insiders.

I'm curious if someone else having this issue can try enabling vim in vscode insiders to see if they have the same experience?

[AlexMenor]

I was blaming vscode for this but indeed seems like its the Vim plugin.

code-insiders doesn't make a difference for me.

[velcroz]

I'm seeing a similar issue. For me, when I press J or K for like a second the cursor afterwards is still catching up while in normal mode.

Same for me, I often overshoot my target code by a few lines because of that

[mrjoedang]

I'm seeing a similar issue. For me, when I press J or K for like a second the cursor afterwards is still catching up while in normal mode.

Same for me, I often overshoot my target code by a few lines because of that

I am getting the same issue.

[rodrei]

same experience here

[austinsantoso]

Same issue here, sometimes after a while, it causes any keyboard input to not be registered at all.

[thai-d-v]

same here, especially on insert mode.

[iamthesiz]

As a temporary workaround, I noticed when uninstalling it, then reinstalling it, it will work well again. This is temporary, but at least it works.

[Twiggeh]

Bumping this, Vim plugin getting unusable, slowdown is only happens in insert mode. Process Explorer points out that there is no high CPU usage, but my memory used for the open window doubles when it slows down.

[noslenac]

I don't see any performance issues while keeping it open. I have it open all day on two computers - Linux Mint 19.3 and Windows 10 (build 18363.628).

Some very old Windows 10 builds seem to struggle occasionally with Electron apps such as VS Code.

[iamthesiz]

I'm on mac Mojave and although I don't experience this issue all the time, it does happen from time to time and it's really annoying. I noticed it happening a lot when I was copying svg xml into JS files.

[pianocomposer321]

I'm experiencing the same lag in motion. Honestly, this is one of the biggest things that makes me almost want to go back to just regular old vim!

[stefabat]

Also in my case I experience a very annoying lag in motion. I am starting to seriously thinking to change editor just for this.

[pianocomposer321]

@stefabat, you might want to try onivim. I can't wait until onivim 2 gets out, b/c it's going to support vscode extensions. But final release for that isn't until after June. :(

[pianocomposer321]

btw, I think my lag is because of enabling vim.foldFix. However, I really need to have the fix, so disabling it is not an option for me.

[stefabat]

@pianocomposer321 onivim and onivim 2 look amazing, I did not know them. However, in the meantime I found an acceptable solution with this vscode extension: neo-vim.
It is much faster than the vim extension, and has more or less everything I need.

[pianocomposer321]

I have tried the extension too (in fact, I uninstalled the vscodevim extension in favor of it), and I agree that performance-wise it is much better. However, it has the same problem that enabling vim.foldFix solved with vscodevim, which is that it opens folds when moving the cursor over them. Several issues have been opened about this, but I don't think there is currently a fix in the works. Incidentally, I believe enabling vim.foldFix is also what caused the lag on vscodevim.

[ecbrodie]

Also running into this problem, with serious lag between my typing and the characters appearing on the screen. I am using the latest version of MacOS (10.15.3), VSCode (1.42.0) and the VIM extension (1.12.4). I don't notice any difference with intellisense being triggered or not. I also notice no difference between editing a large file or a small file (I could easily reproduce my issue in a brand new file).

Just to ensure that other extensions were not getting in the way, I booted up VSCode with a fresh copy of the ~/.vscode directly and only installed the VIM extension. Still getting the issue.

I am sadly forced to disable this extension now because of how much this issue is getting in the way of me being able to write code. I doubt this is something that this extensions maintainers and community desire for :(

[pianocomposer321]

Just out of curiosity, how many of you who are experiencing the lag have enabled vim.foldFix?

[StitiFatah]

Same problem on Archlinux, after a while it takes around a second to switch between normal and insert mode and the input lag makes it pretty unusable. I used to think that was because I always had dozens of tabs so I switched to Vscode Neovim which doesn't have this problem, now that I'm back to VscodeVim I realized the same problem also happens with few tabs if I intensively use Vscode ( 9 hours actually and it's been 1 hour since it became laggy ).
I have the colorizing bar enabled + Bracket Pair Colorizer ( 1 not 2 ) installed. I'll uninstall it and deactivate the color switch and give you feedback.
Did you guys still experience this "bug" btw ?

Edit : 1 month and a half later without pair clorizer and colorized vim status bar and everything is fine, didn't experienced any lag

[leo-mao]

for those Haskell programmer, Haskell-linter cause this issue on win8.1 whilst Bracket Pairs Colorizer 2 is innocent.

[ncharchut]

Pylance was the issue for me (OSX 11.2) in Python files (shocker)

[amantiwari1]

@everyone
same here type is pretty slow any solution!!!

[joeytwiddle]

Do check out your plugins.

I used to have this problem with daosro.stylelint but it went away when I switched to stylelint.vscode-stylelint.

[Alex-EEE]

Bracket Pair Colorizer 2 here as well :-(. (mac Catalina)

Switched to Bracket Pair Colorizer (original version) and it's A OK

[Christopher-Hayes]

Happens to me every time I'm typing a Typescript type. I love having auto-complete, but this drives me nuts considering Vim commands briefly stop working all together.

[mikeRead]

Same here for me, and I cant bring my self to use this :.(

VIM extension disabled holding j (or any key)

With VIM enabled and in insert mode holding j (or any key)

Note: The same amount of "j"s will still be typed but when I release the key it just keeps going at this speed until all "j"s are typed.

EDIT: seems like this issue doesn't happen with neovim extension .

[lassebenni]

For me the Auto Save "afterDelay" option seemed to cause the delay issues.

I switched it off for now.

[rickyzhang82]

It is not only me who feel the same way. What is the fix/workaround?

It is unusable because I type more bugs than code.

[franchesoni]

Reading all "solutions" I suspect that the reason is that the running time of another extension is causing a perceived lag in the vim extension (which doesn't really explain why this happens at entering insert mode)

It happened to me with a large markdown file and the spell checker on

Does this make any sense?

[ZXYFrank]

SWITCH to VScode-Neovim ❗ ❗ ❗
It works incredibly smoothly 😆

[laoshaw]

vim mode indeed feel sluggish under vscode, I disabled all my vim plugs and only had a few key bindings for vscode in .vimrc, still, it's slow, even under normal mode.
switched to vscode-neovim made it usable, faster then vscode-vim for sure, but still slower than terminal vim.

[Mrcuve0]

Test this, it worked for me:
microsoft/vscode#75627 (comment)

[RaviPabari]

Test this, it worked for me: microsoft/vscode#75627 (comment)

Worked for me as well.

[awelzel]

Just leaving this as a datapoint - after disabling git.autorefresh of the vscode.git extension, sluggishness improved noticeable for me (I believe it boiled down to a large number of untracked files in the checkout causing extra load which I now also addressed with .gitignore).

[bariswheel]

Looking over the comments, disaapointing to see this is a problem for almost 4 years. Experiencing the same problems myself. Perhaps it's an extension conflict, would be nice to see if we all have a common extension installed, besides this one.

[theoolee]

@J-Fields

After several days of research around the problem, I suspect that vscode not send command directly to vim extension which cause latency and perhaps other redundant works. Then I add these keybindings to my keybindings.json :

{
  {
    "args": {
      "after": ["a"]
    },
    "command": "vim.remap",
    "key": "a",
    "when": "editorTextFocus"
  },
  {
    "args": {
      "after": ["b"]
    },
    "command": "vim.remap",
    "key": "b",
    "when": "editorTextFocus"
  },
  {
    "args": {
      "after": ["c"]
    },
    "command": "vim.remap",
    "key": "c",
    "when": "editorTextFocus"
  },
  // ... from a to z. maybe from A to Z also needed.
}

Adding keybindings manually is tedious. After all of these done, it seems that vscode send command to vim extension directly, navigation become smooth.

Can we just add these by vim extension automatically or find root cause of the problem through this clue.

[druskus20]

@J-Fields

After several days of research around the problem, I suspect that vscode not send command directly to vim extension which cause latency and perhaps other redundant works. Then I add these keybindings to my keybindings.json :

{
  {
    "args": {
      "after": ["a"]
    },
    "command": "vim.remap",
    "key": "a",
    "when": "editorTextFocus"
  },
  {
    "args": {
      "after": ["b"]
    },
    "command": "vim.remap",
    "key": "b",
    "when": "editorTextFocus"
  },
  {
    "args": {
      "after": ["c"]
    },
    "command": "vim.remap",
    "key": "c",
    "when": "editorTextFocus"
  },
  // ... from a to z. maybe from A to Z also needed.
}

Adding keybindings manually is tedious. After all of these done, it seems that vscode send command to vim extension directly, navigation become smooth.

Can we just add these by vim extension automatically or find root cause of the problem through this clue.

I removed all of my non-vim keybinds and I've only once had a slowdown desync/problem. Maybe that has something to do?

• I must note that I'm usually running vscode without a lot of extensions active. I'd say... 5 to 10 probably.
• I am also running vscode on a 8c/16t CPU, both for my desktop and my laptop
• I've been on this setup for... 6 months maybe

[theoolee]

@druskus20 Running with many extensions is one of the causes. I don't have extension development experience, but I guess that if there are many extension hosts communicating with vscode, it would make vim extension's commands being delayed to execute.

[cpakken]

I think VSCode VIM works on large files just fine ( > 1000 lines). its probably the typescript / javascript intellisense that is bogging it down.

Whenever I open a remote repository in VSCode, it opens into a 'trusted' workspace where a lot of the extensions are disabled or limited use. Even when the file in remote repository is > 1000 lines, vim runs like a hot knife through butter. I played around turning on and off some extensions and I highly suspect its Vscode's native typescript/javascript intellisense extension.

If I open a <200 line typescript file, but with heavy use of generics and complicated types, vim mode slows to a crawl. When vim is off, the normal editor works normally

🤷‍♂️

[onlurking]

For those who come later, this affinity setting helped me out:
microsoft/vscode#75627 (comment)

[Demianeen]

For those who had problems with lagging input from the keyboard in some files, cypress helper + Vim extension together were causing this problem for me.

[marcoshernanz]

microsoft/vscode#75627 (comment) Fixes it, and if that doest fix it try disabling Github Copilot, Tabnine, Codeium or any similar extension

[jedwards1211]

@mikeRead does navigating up/down by holding j/k go faster with the neovim extension?
Some vim extensions unbind from the type command in edit mode, letting VSCode itself handle keyboard input in the main process instead of having to stupidly send all keypresses over IPC. The VSCode team decided early on not to let any extensions run in the main process, which has had a disastrous impact on Vim emulation. It was a truly awful design choice.

[jedwards1211]

@onlurking I've had affinity set for a long time and it doesn't fix the gradual slowdown. I still suspect VSCode itself is at fault for this issue, but who knows.

[onlurking]

Hey @jedwards1211 I migrated to vscode-neovim quite few months ago, it has it fair share of issue (eg sync issues when using Supermaven/Copilot), but it doesn't have the same slow down problem of VSCodeVim.