Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Vim plugin slows vscode down. #2021

Open
Kesanov opened this issue Sep 15, 2017 · 165 comments
Open

Vim plugin slows vscode down. #2021

Kesanov opened this issue Sep 15, 2017 · 165 comments

Comments

@Kesanov
Copy link

Kesanov commented Sep 15, 2017

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
Copy link

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
Copy link

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

@theprash
Copy link

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:
small

Maximised (2048x1152 with 125% scaling):
large

@movsb
Copy link

movsb commented Jan 18, 2018

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

@kennym
Copy link

kennym commented Feb 1, 2018

Any fixes?

@Chillee
Copy link
Member

Chillee commented Feb 2, 2018

@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
Copy link
Member

jpoon commented Feb 2, 2018

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

@johnfn
Copy link
Member

johnfn commented Feb 3, 2018

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
Copy link
Member

Chillee commented Feb 4, 2018

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
Copy link
Member

Chillee commented Feb 4, 2018

@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
Copy link

saites commented Mar 12, 2018

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
Copy link

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
Copy link

saites commented Mar 13, 2018

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
Copy link

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

@jpoon
Copy link
Member

jpoon commented Mar 13, 2018

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

@saites
Copy link

saites commented Mar 13, 2018

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
Copy link

@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
Copy link
Member

Chillee commented Mar 14, 2018

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
Copy link

Having really bad lag issues on OSX as well

@vxio
Copy link

vxio commented Apr 12, 2018

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
Copy link

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

@Diadlo
Copy link

Diadlo commented Apr 18, 2018

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
Copy link

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
Copy link

Peluko commented May 2, 2018

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
Copy link

acicovic commented May 2, 2018

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

@Peluko
Copy link

Peluko commented May 2, 2018

@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
Copy link

jrwrigh commented May 11, 2018

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
Copy link

acicovic commented May 13, 2018

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

@J-Fields
Copy link
Member

J-Fields commented Jan 7, 2020

@e-z-p How big is the file? Is it this slow with all other extensions disabled?

@djalan
Copy link

djalan commented Jan 16, 2020

@djalan You're probably talking about nvidia-settings?

image

@sarpik I unchecked the third option called "Allow G-SYNC/G-SYNC Compatible"

image

@jedwards1211
Copy link

jedwards1211 commented Jan 30, 2020

https://code.visualstudio.com/api/advanced-topics/extension-host

The Extension Host in VS Code prevents extensions from:

  • Impacting startup performance
  • Slowing down UI operations

VSCodeVim's perf issues demonstrate how completely the Extension Host fails at this mission. The extra complexity it adds to implementing and debugging extensions is clearly not worth it.

@xy137
Copy link

xy137 commented Mar 3, 2020

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
Copy link

takas3 commented Apr 3, 2020

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

@st-schneider
Copy link

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

@chasingmaxwell
Copy link

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
Copy link

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
Copy link

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
Copy link

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
Copy link

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
Copy link

ghost commented May 16, 2020

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
Copy link

jensbodal commented May 16, 2020

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
Copy link
Member

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

@hiro0604-0120
Copy link

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
Copy link

ghost commented May 19, 2020

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
Copy link

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
Copy link

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
Copy link

yuchen16 commented Apr 7, 2021

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

@reinux
Copy link

reinux commented Apr 7, 2021

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
Copy link
Member

J-Fields commented Apr 7, 2021

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
Copy link

reinux commented Apr 7, 2021

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
Copy link
Member

J-Fields commented Apr 7, 2021

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

@reveriel
Copy link

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

@PeterAaser
Copy link

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
Copy link

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

@Mrcuve0
Copy link

Mrcuve0 commented Aug 5, 2022

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
Copy link

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests