VSCodeVIM is unusable (incredibly slow) on larger files, especially in INSERT MODE

[jsonMartin]

• Click thumbs-up 👍 on this issue if you want it!
• Click confused 😕 on this issue if not having it makes VSCodeVim unusable.

The VSCodeVim team prioritizes issues based on reaction count.

---

Is this a BUG REPORT or FEATURE REQUEST? (choose one): BUG REPORT

Environment:

• VSCode Version: 1.18.1 (I have tried Insiders build too, and didn't work there either)
• VsCodeVim Version: 0.15.5
• OS: MacOS High Siera

What happened: When editing longer files, VSCodeVim becomes so slow as to be completely unusable. Typing in insert mode, the keyboard response lags so hard it is impossible to use for anything other than reading files (I've had to switch back to Jetbrains IDE to work on this project in the meantime, since that's the only other IDE I have with a decent VIM plugin).

I've included some GIFs below to show this bug in action. Note that I type 100+ WPM, and these videos are in real-time, running at 30FPS.

On a <100 line file, typing doesn't seem to have much of a delay:

On a 1-2K line file, typing is already noticeably so slow that it is completely impossible to use:

On a 10K line file, typing is even slower and more unusable:

However, doing VIM commands in normal mode like navigating words seems to work at normal speed, and commands such as copy/pasting etc works (yank and paste is still a little slower but nowhere near as slow as insert mode):

Disabling the VIM extension allows typing in real time, even on the largest 10K+ files:

What did you expect to happen:

Key presses type in real time on files, without an unusable delay. It should behave at the same or similar speed to how editing performs with VIM disabled.

How to reproduce it:

Type in insert mode on large files with the newest version of VSCodeVim and VSCode.

[jsonMartin]

FYI, just also want to note that I have already seen the other issues here about the Status Bar color & neovim integration bug causing slow behavior, and have already disabled all of those options as well - it made no difference with this issue.

[jonathansty]

I'm experiencing performance issues even in smaller files (100-150 lines). I've disabled all my extensions while trying it out. Without the vscode-vim extension typing feels responsive and there's no slowdowns. With it, I often experience freezes etc. Any idea how to figure out what might be causing this?

[rickstaa]

I have the same problem. I am forced to disable the VIM extension till this is fixed. Thanks in advance

[landau]

I never had a problem with speed until recently, since latest VSCode update. Navigation (J,K, etc) is basically unusable. Insert mode movement is fine.

VSCODE: Version 1.26.1 (1.26.1) OSX: 10.13.6

[matbess]

I have the same issue with J,K, etc...

VSCODE: Version 1.26.1 (1.26.1) OS: Windows 10 Pro

I had to disable VsVim.

[naddeoa]

I can cause input lag by saving changes to a file. If I add a new line, save, spam h, then the cursor will freeze for a second or two.

EDIT: It might have something to do with the size of my workspace. When I open my packages individually instead of as one big workspace then it seems ok.

[smiller6]

vscode: 1.27.2 vscodevim: 0.16.4

I notice significant slowdown when typing in insert mode for multiple lines without returning to normal mode. If I return to normal mode, and then back to insert mode, the performance improves considerably for a short while. The behavior is consistent regardless whether I am operating in a workspace or just an untitled buffer, with no other files open.

I too observed the slowdown on large files; I don't think it is the sole fault of vscodevim. In my case it appears to be a conflict between vscodevim and 'spellright'. Spellright or vscodevim cause no issue by themselves for a large file on my system, but are unusable together. Intuitively, this would conflict would likely extent to other plugins that tried to behave in a similar way, meaning that others with similar combinations of plugins while using vscodevim are likely to experience this as well.

[Astrantia]

This is still an issue. @jpoon @Chillee what's the point of adding more features when the extension makes whole vscode unusable with current features? Performance should be number 1 priority for vscodevim now.

[shawnaxsom]

I'm taking a look. I was able to reproduce. I opened editorBrowser.ts in vscode codebase, and I just tried copying/pasting the import statements in that file many times. Typing is definitely delayed compared to without the extension.

[shawnaxsom]

For those experiencing issues, it would be helpful to know:

• Have you all tried disabling all other extensions, and do you still experience the slowness?
• Can you share an example publicly available project where you experience the slowness even without other plugins enabled?
• Can you share your vscode configuration as well?

In this case where I could reproduce slowness, the issue ended up being from the popular Import Cost extension, not from VSCodeVim.

https://cl.ly/3705a8a1b59b

Note that I am typing at the same speed on both, and I think that gif looks faster than I experienced it. The issue is fixed if I remove VSCodeVim OR Import Cost. But I stripped all of VSCodeVim's code out so all it is doing is passing typing commands back to VSCode:

/**
 * Extension.ts is a lightweight wrapper around ModeHandler. It converts key
 * events to their string names and passes them on to ModeHandler via
 * handleKeyEvent().
 */
import * as vscode from 'vscode';
import * as _ from 'lodash';

export async function activate(context: vscode.ExtensionContext) {
  // override vscode commands
  overrideCommand(context, 'type', async args => {
    vscode.commands.executeCommand('default:type', { text: args.text });
  });
}

function overrideCommand(
  context: vscode.ExtensionContext,
  command: string,
  callback: (...args: any[]) => any
) {
  const disposable = vscode.commands.registerCommand(command, async args => {
    callback(args);
  });
  context.subscriptions.push(disposable);
}

I'm not sure why Import Cost handles things differently if we are doing that. It probably isn't realistic for Import Cost to handle 400+ imports in one file, but I wonder how many people experiencing slowness are having issues with another conflicting plugin.

[shawnaxsom]

See #2021 for some updates. I have a fix that should speed up performance considerably for many users. I hope to have a PR up sometime this week. If there are still delays, I can look into other potential optimizations or causes.

[shawnaxsom]

One PR was merged with optimizations. It should help, but not necessarily fix the issue for everyone. Feel free to leave feedback after our next release.

I'll be testing performance further with a user likely early next week.

[fungiboletus]

The PR improved things but it's sometimes still very slow with large files. So slow that the editor is sometimes lagging behind and executing wrong commands (because it didn't exit insert mode on time for example).

[shawn-pe]

Thanks for the feedback. I'm hoping to test with that user possibly next week. I apologize that I've been busy from a job change and will be flying out of town for the job over the weekend, but hope to make progress soon.

[shawnaxsom]

I did a screen share with a user this evening and we found slowness was mainly in Visual Studio itself. Even if we just override their "type" command, and send the keys pressed back to them with executing the "default:type" command, it still was taking often 180ms or more for a single character. It was much faster if we didn't override the "type" command at all, but it should theoretically be doing the same thing in either case.

I may have to open an issue with VSCode.

[chulander]

i have to restart vscode every maybe 5 hours of work because of the incredibly laggy insert mode also. unfortunate since this is the best vim extension . good job to the maintainers for building this tho!

[naddeoa]

I have no idea what was causing this for me, but it used to happen when I had large workspaces. I didn't change anything and I don't have this issue anymore as of a few weeks ago. There have been a few vscode updates since then but nothing stands out as a user.

On Fri, Jan 18, 2019 at 7:48 AM Bryan Chu notifications@github.com wrote:

i have to restart vscode every maybe 5 hours of work because of the incredibly laggy insert mode also. unfortunate since this is the best vim extension . good job to the maintainers for building this tho!

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/VSCodeVim/Vim/issues/2216#issuecomment-455591529, or mute the thread https://github.com/notifications/unsubscribe-auth/ABLTLbXH4Abfem5VFzJbe1uS9oP23aC1ks5vEezogaJpZM4Q_gEp .

[swsalsify]

Can be slow even with a single file open. Not sure if this is strictly VSCodeVim's fault or if it has to do with the editor's internal text model.

Here's the scenario that drove me to comment just now:

1. opened a moderate-size (15KB) compacted (single line, no whitespace) JSON file
2. run %s/<A>/<B>/g (dozens of matches) -- this step was more or less instantaneous
3. undo -- watch each replacement individually revert for roughly half a minute
4. redo -- watch each replacement location incrementally update again. Seems like this operation should complete about as fast as the original substitute command even if undo is expensive for some reason.

I'm happy with VSCodeVim for most development; processing larger data files like this is where I typically find frustration.

[yoshida-m-3]

The same problem occurred when I edited a file of 100 million lines with PHP. In my case, it turned out that I disabled the extension "Visual Studio IntelliCode". It seems that processing is done in the background every time you edit.

[Chillee]

I believe the fundamental issue is that all extensions run on the same thread. So, when you have a beefy language service chewing through your CPU, it inevitably increases latency for vscodevim. I remember the VSCode team was considering allowing some extensions to create another thread - I'm not sure if anything came of that.

[plbowers]

I have NO extensions except Vim 1.9.0 installed on VSCode.

If the file is very small (20-30 lines) then performance is fine.

If I have disable Vim then performance is fine.

If I have a few hundred lines of code and try to type (problem is primarily in input mode - I haven't noticed a big lag on movement or yank/delete/put/etc) then the performance is unbearable.

Temporarily moving back to Vim. Hoping to move back to VSCode/Vim when this is solved.

EDIT: Based on another issue/thread here I went and changed my Editor.QuickSuggestions to false and that has improved the issue roughly 95%.

[arthakdoo]

Vim plugin for Visual Studio Code has become unacceptably slow when reacting to commands and switching between modes, constantly leaving behind, scrambled letters, changing order of what I typed etc. I'll either have to switch back to WebStorm whose plugin for Vim wasn't so bad, or turn off Vim mode and use fc*g <- arrows -> up / down without it

[Rasie1]

This plugin seems to have the best range of vim features, but is unusable because of performance. I have laptop with i7-8500U and have next issues:

1. After using counts, macros, etc, characters are inserted one by one at the rate of about 300 characters per second. Why can't it insert everything at once?
2. High CPU usage. Everything becomes slower with increasing file size, especially one-by-be character insertions I mentioned above

[jjangun]

I had used with VSCodeVim with One dark pro theme. It was extreamly slow on larger files. I removed One dark pro and then tested again I couldn't reproduce it. I think VSCodeVim and One dark pro theme are not good combination. If you had same problems please remove One dark pro theme.

[J-Fields]

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]

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.

[vlad2135]

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.

Disabling Bracket plugin helped me with editing performance. For info, I have a 31k lines JSON file with folded sections, fold navigation hack is enabled.

[jonvuri]

@J-Fields I confirmed something very similar with https://marketplace.visualstudio.com/items?itemName=2gua.rainbow-brackets instead. Thanks for the tip!

[caleywoods]

@vlad2135 Disabling bracket pair colorizer (the original) seems to have fixed my slow performance issue with exiting insert mode and returning to normal mode. Thank you.

[hype08]

can confirm, disabling Bracket Pair Colorizer seems to do the trick! on a file with 4K lines, seems to be okay with toggling between insertion/normal. will leave VSCode on for an extended duration to see if anything changes, thank you @J-Fields for the tip!

[J-Fields]

Version 1.13.0 introduces the vim.experimentalOptimizations setting, which significantly improves the performance in large files.

[alapin92]

Any better choice of bracket colorizer extension, folks? Hard to turn it off..

[aquaductape]

@alapin92 Rainbow Brackets and Bracket Pair Colorizer(original) are better alternatives in performance than Bracket Pair Colorizer 2

[vegerot]

@J-Fields I don't see any documentation on this option. What does it do?

[J-Fields]

@vegerot It avoids some unnecessary computation we do to keep track of undo/redo history. We've got a simpler and more effective way of doing the same thing that's baked in (no config) coming next release.

[vegerot]

Thank you

[swenyang]

@alapin92 Rainbow Brackets and Bracket Pair Colorizer(original) are better alternatives in performance than Bracket Pair Colorizer 2

To me, turning on either one of Rainbow Brackets and Indent Rainbow will make VSCode very slow on large files. Enabling vim.experimentalOptimizations doesn't mitigate this issue. Had to turn them off.

[chtenb]

Editing a 10 MB csv files works fine it seems, but in a 50 MB VSCodeVim refuses to do anything. Scrolling and moving with the mouse works without any lag, but I just can't type anything.

[PhilippKorn]

Is vim.experimentalOptimizations still a feature? I cannot find the setting. I'm using versison 1.21.7. My code version is 1.60.1 (Vscodium).

[meercan]

I had this issue even in files with <2k lines, reading this thread I figured it might be cause by some other extension. This resolved my issue:

• I disabled all extensions I had,
  • cmd + p
  • disable all extensions
• This resolved the issue, then
• Starting from the extensions I think I definitely need, I enabled them one by one and checked if the issue re-appeared
• There was a buch of other disabled extensions left which I didn't need, I uninstalled them I don't know which extension caused it but this elimination method fixed the issue for me.

[vegerot]

@meercan next time try VSCode Extension bisecting

[meercan]

VSCode Extension bisecting

uuu fancy! Thanks!