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
Josef-Vonasek opened this issue Sep 15, 2017 · 153 comments
Open

Vim plugin slows vscode down. #2021

Josef-Vonasek opened this issue Sep 15, 2017 · 153 comments

Comments

@Josef-Vonasek
Copy link

@Josef-Vonasek Josef-Vonasek 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

@theprash theprash commented Sep 15, 2017

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

@theprash theprash commented Sep 15, 2017

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

@theprash
Copy link

@theprash theprash commented Sep 15, 2017

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 movsb commented Jan 18, 2018

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

@kennym
Copy link

@kennym kennym commented Feb 1, 2018

Any fixes?

@Chillee
Copy link
Member

@Chillee 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 jpoon commented Feb 2, 2018

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

@johnfn
Copy link
Member

@johnfn 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 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 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 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

@armoucar armoucar commented Mar 13, 2018

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

@armoucar armoucar commented Mar 13, 2018

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 jpoon commented Mar 13, 2018

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

@saites
Copy link

@saites 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

@armoucar armoucar commented Mar 14, 2018

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

@BWoodfork BWoodfork commented Mar 28, 2018

Having really bad lag issues on OSX as well

@vxio
Copy link

@vxio 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

@dyxushuai dyxushuai commented Apr 13, 2018

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

@Diadlo
Copy link

@Diadlo 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

@acicovic acicovic commented Apr 25, 2018

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 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 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 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 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 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.

@djmittens
Copy link

@djmittens djmittens commented Dec 3, 2019

mine was a 1.4k line C++ file and it was really fast.

@kiprasmel
Copy link

@kiprasmel kiprasmel commented Dec 19, 2019

C-e / C-y is really laggy, especially if held down to execute multiple times;

everything else seems fine.

I've disabled all my extensions except vim, and it's still the same.
Tested both in vscodium & code-insiders. Files were pretty small, < 100 LOC

My setup: https://gist.github.com/sarpik/de9160a0602463fb752f2d84d7aa4fd8
via https://marketplace.visualstudio.com/items?itemName=Shan.code-settings-sync (don't override your own settings though)

$ uname -a
Linux arch-usb 5.4.3-arch1-1 #1 SMP PREEMPT Fri, 13 Dec 2019 09:39:02 +0000 x86_64 GNU/Linux

$ vscodium --version
1.41.0
9579eda04fdb3a9bba2750f15193e5fafe16b959
x64

$ code-insiders --version
1.42.0-insider
e74405d11443c5361c31e2bc341866d146eee206
x64
@J-Fields
Copy link
Member

@J-Fields J-Fields commented Dec 29, 2019

I did some digging and identified an issue in either VSCode or in the typescript language server that is causing us a lot of grief. If you're interested, follow this issue.

@J-Fields
Copy link
Member

@J-Fields J-Fields commented Dec 29, 2019

After a bit of digging, I discovered that this is the fault of Bracket Pair Colorizer 2. If anyone else has this extension (or similar) enabled, try disabling it and see if that improves performance for you. I'm going to investigate if that extension can be optimized, as it's very helpful to me.

@bm-stschneider
Copy link

@bm-stschneider bm-stschneider commented Dec 29, 2019

I don't have that extension installed.

@J-Fields
Copy link
Member

@J-Fields J-Fields commented Dec 29, 2019

A broader point is this: the extension host is, if I remember correctly, single-threaded, so VSCodeVim needs to wait its turn, and can't help making the editor unresponsive when it does so.

There are optimizations to be made in this extension, but if performance on anything smaller than huge files is a consistent issue for you, try disabling other extensions and see if that helps!

Edit: here's a discussion on the topic I was having trouble finding earlier: microsoft/vscode#75627

@djalan
Copy link

@djalan djalan commented Jan 1, 2020

I solved this probem by deactivating Nvidia GSync under Linux Manjaro. VSCode is based on Electron/Chromium and Chrome browser had really bad lag before I deactivated GSync. Now VSCode VIM plugin is PERFECT and FAST.

@kiprasmel
Copy link

@kiprasmel kiprasmel commented Jan 1, 2020

@djalan More details on how you deactivated gsync, please?
I myself now went through https://wiki.archlinux.org/index.php/Variable_refresh_rate but I haven't experienced a performance improvement.

@djalan
Copy link

@djalan djalan commented Jan 2, 2020

@sarpik I have installed nvidia drivers under manjaro and they have a GUI where you can do this. I didnt't have to edit xorg.conf manually or do any command line type of stuf

@kiprasmel
Copy link

@kiprasmel kiprasmel commented Jan 2, 2020

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

image

@emansrazor
Copy link

@emansrazor emansrazor commented Jan 7, 2020

100aa<esc> takes literal ~4 seconds to complete. how to fix.

@J-Fields
Copy link
Member

@J-Fields 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 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 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 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 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.

@bm-stschneider
Copy link

@bm-stschneider bm-stschneider commented Apr 3, 2020

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

@chasingmaxwell
Copy link

@chasingmaxwell chasingmaxwell commented Apr 8, 2020

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

@jensbodal jensbodal commented Apr 8, 2020

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.

@bm-stschneider
Copy link

@bm-stschneider bm-stschneider commented Apr 9, 2020

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

@adriaangraas adriaangraas commented Apr 29, 2020

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

@skplunkerin skplunkerin commented Apr 29, 2020

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

@J-Fields J-Fields commented May 16, 2020

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

@hiro0604-0120
Copy link

@hiro0604-0120 hiro0604-0120 commented May 17, 2020

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 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?

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

Successfully merging a pull request may close this issue.

None yet
You can’t perform that action at this time.