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 · 85 comments

Comments

Projects
None yet
@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

This comment has been minimized.

Show comment
Hide comment
@theprash

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

This comment has been minimized.

Show comment
Hide comment
@theprash

theprash Sep 15, 2017

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

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

This comment has been minimized.

Show comment
Hide comment
@theprash

theprash 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

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

This comment has been minimized.

Show comment
Hide comment
@movsb

movsb Jan 18, 2018

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

movsb commented Jan 18, 2018

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

@kennym

This comment has been minimized.

Show comment
Hide comment
@kennym

kennym Feb 1, 2018

Any fixes?

kennym commented Feb 1, 2018

Any fixes?

@Chillee

This comment has been minimized.

Show comment
Hide comment
@Chillee

Chillee Feb 2, 2018

Member

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

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

This comment has been minimized.

Show comment
Hide comment
@jpoon

jpoon Feb 2, 2018

Member

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

Member

jpoon commented Feb 2, 2018

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

@johnfn

This comment has been minimized.

Show comment
Hide comment
@johnfn

johnfn Feb 3, 2018

Member

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

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

This comment has been minimized.

Show comment
Hide comment
@Chillee

Chillee Feb 4, 2018

Member

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?

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

This comment has been minimized.

Show comment
Hide comment
@Chillee

Chillee Feb 4, 2018

Member

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

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

This comment has been minimized.

Show comment
Hide comment
@saites

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

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

This comment has been minimized.

Show comment
Hide comment
@armoucar

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

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

This comment has been minimized.

Show comment
Hide comment
@saites

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

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

This comment has been minimized.

Show comment
Hide comment
@armoucar

armoucar Mar 13, 2018

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

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

This comment has been minimized.

Show comment
Hide comment
@jpoon

jpoon Mar 13, 2018

Member

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

Member

jpoon commented Mar 13, 2018

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

@saites

This comment has been minimized.

Show comment
Hide comment
@saites

saites 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

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

This comment has been minimized.

Show comment
Hide comment
@armoucar

armoucar 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

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

This comment has been minimized.

Show comment
Hide comment
@Chillee

Chillee Mar 14, 2018

Member

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

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

This comment has been minimized.

Show comment
Hide comment
@BWoodfork

BWoodfork Mar 28, 2018

Having really bad lag issues on OSX as well

BWoodfork commented Mar 28, 2018

Having really bad lag issues on OSX as well

@xiao-vincent

This comment has been minimized.

Show comment
Hide comment
@xiao-vincent

xiao-vincent 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,

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

This comment has been minimized.

Show comment
Hide comment
@dyxushuai

dyxushuai Apr 13, 2018

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

dyxushuai commented Apr 13, 2018

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

@Diadlo

This comment has been minimized.

Show comment
Hide comment
@Diadlo

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

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

This comment has been minimized.

Show comment
Hide comment
@acicovic

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

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

This comment has been minimized.

Show comment
Hide comment
@Peluko

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

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

This comment has been minimized.

Show comment
Hide comment
@acicovic

acicovic May 2, 2018

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

acicovic commented May 2, 2018

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

@Peluko

This comment has been minimized.

Show comment
Hide comment
@Peluko

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

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.

@u2berggeist

This comment has been minimized.

Show comment
Hide comment
@u2berggeist

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

u2berggeist 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

This comment has been minimized.

Show comment
Hide comment
@acicovic

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

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.

@jpoon

This comment has been minimized.

Show comment
Hide comment
@jpoon

jpoon Sep 7, 2018

Member

@JesseObrien I don't think anybody is actively looking into this. Contributions are wholly welcomed.

Member

jpoon commented Sep 7, 2018

@JesseObrien I don't think anybody is actively looking into this. Contributions are wholly welcomed.

@claytongulick

This comment has been minimized.

Show comment
Hide comment
@claytongulick

claytongulick Sep 13, 2018

Same boat here, win 10, brand new tricked out surface book 2, all the bells and whistles.

With this plugin enabled, typing in insert mode slows down to the speed of a 1200 baud modem on a noisy loop (yes, I'm old). I can type several lines of code before it "catches up". Makes vscode unusable in it's current form.

Ironic, since I switched to vscode from webstorm because that editor was too slow and bloated, now I might have to switch back just to be able to get work done :-(

If I wasn't working till 4am every day on this project, I'd jump in and try to fix the issue. Maybe I'll be able to once sanity resumes.

Thanks for the great extension though, I wouldn't be able to use vscode at all without it!

P.S. - hiding the status bar via user settings improved things a bit, still pretty laggy though. Maybe 2400 baud modem? 😄

claytongulick commented Sep 13, 2018

Same boat here, win 10, brand new tricked out surface book 2, all the bells and whistles.

With this plugin enabled, typing in insert mode slows down to the speed of a 1200 baud modem on a noisy loop (yes, I'm old). I can type several lines of code before it "catches up". Makes vscode unusable in it's current form.

Ironic, since I switched to vscode from webstorm because that editor was too slow and bloated, now I might have to switch back just to be able to get work done :-(

If I wasn't working till 4am every day on this project, I'd jump in and try to fix the issue. Maybe I'll be able to once sanity resumes.

Thanks for the great extension though, I wouldn't be able to use vscode at all without it!

P.S. - hiding the status bar via user settings improved things a bit, still pretty laggy though. Maybe 2400 baud modem? 😄

@jondot

This comment has been minimized.

Show comment
Hide comment
@jondot

jondot Sep 13, 2018

For anyone that's still bumping into this: you can disable this specific feature, look for the statusBarColorControl key and turn it off.

jondot commented Sep 13, 2018

For anyone that's still bumping into this: you can disable this specific feature, look for the statusBarColorControl key and turn it off.

@cmcclellen

This comment has been minimized.

Show comment
Hide comment
@cmcclellen

cmcclellen Sep 21, 2018

Also having this problem, but as of 1.27.2 its ever present now. Basically, on any file that has syntax highlighting (esp typescript), this plugin causes heavy typing lag in any decent sized project.

Unfortunately I'm new to VSCode plugins so I'm not the best person to look into this. However, here are some things from running the profiler.

The test I do is just basically go into insert mode, and hold a key down and watch it repeat. When I stop holding down the key, the character continues to repeat for a few seconds afterwards. You can see vscode stuttering/not keeping up. Its the same thing with normal typing -- I see vscode stuttering and I am out typing the editor with the plugin on. I'm on a beefy machine too, and it definitely seems related to having a project with many files being considered for intellisense. With other vim-like plugins, this behavior does not occur. Also vsvim with no folder open and just an empty file is reasonably fast. I do these tests with ONLY the vim plugin active.

I did run the profiler to see what is going on. Most of the time is spent in net.js onread. I've attached a quick screenshot to show what it looks like. In this screen shot I was just typing really fast. It looks roughly the same if I just hold a key down.

image

cmcclellen commented Sep 21, 2018

Also having this problem, but as of 1.27.2 its ever present now. Basically, on any file that has syntax highlighting (esp typescript), this plugin causes heavy typing lag in any decent sized project.

Unfortunately I'm new to VSCode plugins so I'm not the best person to look into this. However, here are some things from running the profiler.

The test I do is just basically go into insert mode, and hold a key down and watch it repeat. When I stop holding down the key, the character continues to repeat for a few seconds afterwards. You can see vscode stuttering/not keeping up. Its the same thing with normal typing -- I see vscode stuttering and I am out typing the editor with the plugin on. I'm on a beefy machine too, and it definitely seems related to having a project with many files being considered for intellisense. With other vim-like plugins, this behavior does not occur. Also vsvim with no folder open and just an empty file is reasonably fast. I do these tests with ONLY the vim plugin active.

I did run the profiler to see what is going on. Most of the time is spent in net.js onread. I've attached a quick screenshot to show what it looks like. In this screen shot I was just typing really fast. It looks roughly the same if I just hold a key down.

image

@samueltlg

This comment has been minimized.

Show comment
Hide comment
@samueltlg

samueltlg Sep 21, 2018

Looks like the biggest clue to the problem so far! Hopefully someone is willing to fix this; I imagine by now it would make a lot of our vs-code lives a lot more pleasant (with having usable vim emulation).

samueltlg commented Sep 21, 2018

Looks like the biggest clue to the problem so far! Hopefully someone is willing to fix this; I imagine by now it would make a lot of our vs-code lives a lot more pleasant (with having usable vim emulation).

@shawnaxsom

This comment has been minimized.

Show comment
Hide comment
@shawnaxsom

shawnaxsom Sep 22, 2018

Contributor

@cmcclellen It would be helpful if you could right click on that profile view and save the profile for others to view. Is there a public project that you are experiencing the issue on? I would be happy to take a look, but I'm not experiencing the same issues if I load a substantial TypeScript project like the vscode project itself.

Contributor

shawnaxsom commented Sep 22, 2018

@cmcclellen It would be helpful if you could right click on that profile view and save the profile for others to view. Is there a public project that you are experiencing the issue on? I would be happy to take a look, but I'm not experiencing the same issues if I load a substantial TypeScript project like the vscode project itself.

@shawnaxsom

This comment has been minimized.

Show comment
Hide comment
@shawnaxsom

shawnaxsom Sep 23, 2018

Contributor

This issue is similar to #2216.

As I mention there, I thought I was able to reproduce the slowness issues, but it ended up being caused by the Import Cost extension, not VSCodeVim by itself.

The issues described here sound different than what I saw (people experiencing issues with no other extensions installed). I haven't been able to reproduce that yet. But anyone visiting that does have other extensions installed should try disabling them all and checking whether that helps.

I didn't find any issues with our handling of the code. The only part that was slow in our code was updateView, just where it calls setContext it was taking 300ms if I spammed in insert mode. But it takes just 0-6ms again if I remove the Import Cost extension.

  public async updateView(
   [...]
    const foo = console;
    foo.time('setContext');
    // This is only slow for me with Import Cost enabled on a file with many imports
    await vscode.commands.executeCommand(
      'setContext',
      'vim.mode',
      ModeName[this.vimState.currentMode]
    );
    foo.timeEnd('setContext');
}

@cmcclellen This may be the case for you. Have you tried testing without Import Cost extension or other extensions? If you are experiencing the delay in TypeScript projects, and not experiencing it with empty projects, and you see high net.js onread, I was seeing the same issues. It seemed that possibly VSCodeVim typing was triggering Import Cost to re-read imported files and check the file size, which I assume to be the net.js onread call.

Contributor

shawnaxsom commented Sep 23, 2018

This issue is similar to #2216.

As I mention there, I thought I was able to reproduce the slowness issues, but it ended up being caused by the Import Cost extension, not VSCodeVim by itself.

The issues described here sound different than what I saw (people experiencing issues with no other extensions installed). I haven't been able to reproduce that yet. But anyone visiting that does have other extensions installed should try disabling them all and checking whether that helps.

I didn't find any issues with our handling of the code. The only part that was slow in our code was updateView, just where it calls setContext it was taking 300ms if I spammed in insert mode. But it takes just 0-6ms again if I remove the Import Cost extension.

  public async updateView(
   [...]
    const foo = console;
    foo.time('setContext');
    // This is only slow for me with Import Cost enabled on a file with many imports
    await vscode.commands.executeCommand(
      'setContext',
      'vim.mode',
      ModeName[this.vimState.currentMode]
    );
    foo.timeEnd('setContext');
}

@cmcclellen This may be the case for you. Have you tried testing without Import Cost extension or other extensions? If you are experiencing the delay in TypeScript projects, and not experiencing it with empty projects, and you see high net.js onread, I was seeing the same issues. It seemed that possibly VSCodeVim typing was triggering Import Cost to re-read imported files and check the file size, which I assume to be the net.js onread call.

@samueltlg

This comment has been minimized.

Show comment
Hide comment
@samueltlg

samueltlg Sep 23, 2018

Many people here, including myself, have this issue without any extensions installed. Sure, having additional extensions may exacerbate it, but even without, it is unusable here when it is the only extension. A lot of those here report the issue being on windows machines also, but if you read through there are reports of the problem (with no extensions) on high-end machines with vs code on Linux, too, so it seems to be across the board. I think a couple have suggested that the cause could be how vscode-vim interacts with certain graphic card families (the problem can be lessened greatly by reducing the editor window width).

samueltlg commented Sep 23, 2018

Many people here, including myself, have this issue without any extensions installed. Sure, having additional extensions may exacerbate it, but even without, it is unusable here when it is the only extension. A lot of those here report the issue being on windows machines also, but if you read through there are reports of the problem (with no extensions) on high-end machines with vs code on Linux, too, so it seems to be across the board. I think a couple have suggested that the cause could be how vscode-vim interacts with certain graphic card families (the problem can be lessened greatly by reducing the editor window width).

@shawnaxsom

This comment has been minimized.

Show comment
Hide comment
@shawnaxsom

shawnaxsom Sep 23, 2018

Contributor

@samueltlg Yeah I am sure there are multiple causes for the slowness. What @cmcclellen describes doesn't sound as likely to be from the same root cause as other users have described. Hopefully his issue at least is resolved by removing an extension like Import Cost. For other users, I wish I could reproduce the issue to help.

I would be happy to do a screen share to look into the issue for anyone that can reproduce. You can find me on our https://vscodevim.slack.com Slack channel. The profiler was pretty noisy when I was debugging, so we'd probably just debug by putting some console.time statements in extension.ts for overrideCommand(context, 'type', async args => {}).

Contributor

shawnaxsom commented Sep 23, 2018

@samueltlg Yeah I am sure there are multiple causes for the slowness. What @cmcclellen describes doesn't sound as likely to be from the same root cause as other users have described. Hopefully his issue at least is resolved by removing an extension like Import Cost. For other users, I wish I could reproduce the issue to help.

I would be happy to do a screen share to look into the issue for anyone that can reproduce. You can find me on our https://vscodevim.slack.com Slack channel. The profiler was pretty noisy when I was debugging, so we'd probably just debug by putting some console.time statements in extension.ts for overrideCommand(context, 'type', async args => {}).

@cmcclellen

This comment has been minimized.

Show comment
Hide comment
@cmcclellen

cmcclellen Sep 24, 2018

@shawnaxsom The project i was working on isn't public unfortunately. The problems experienced were with no other plugins installed -- only vscode vim. What I'm seeing is tons of calls to the lang server. Ie, it looks like tsserver is getting spammed, and which is why I'm seeing thousands of net reads in a short period just typing.

I'll try to get on slack and see if I can show you what its doing. And to @samueltlg above -- VS code is running at 2560x1440. If I shrink it down it gets noticeably faster, but still somewhat laggy. Also, turning on Zen mode speeds it up the most. At full resolution with zen mode on, even with a full set of plugins, its fast no lag.

cmcclellen commented Sep 24, 2018

@shawnaxsom The project i was working on isn't public unfortunately. The problems experienced were with no other plugins installed -- only vscode vim. What I'm seeing is tons of calls to the lang server. Ie, it looks like tsserver is getting spammed, and which is why I'm seeing thousands of net reads in a short period just typing.

I'll try to get on slack and see if I can show you what its doing. And to @samueltlg above -- VS code is running at 2560x1440. If I shrink it down it gets noticeably faster, but still somewhat laggy. Also, turning on Zen mode speeds it up the most. At full resolution with zen mode on, even with a full set of plugins, its fast no lag.

@cmcclellen

This comment has been minimized.

Show comment
Hide comment
@cmcclellen

cmcclellen Sep 24, 2018

FYI we made some progress today via a screenshare. Thanks @shawnaxsom for taking the time to look into the issue. Just wanted to let people know who are tracking this issue that progress was made, but I'll leave it to Shawn to give details about it as I don't want to be inaccurate.

cmcclellen commented Sep 24, 2018

FYI we made some progress today via a screenshare. Thanks @shawnaxsom for taking the time to look into the issue. Just wanted to let people know who are tracking this issue that progress was made, but I'll leave it to Shawn to give details about it as I don't want to be inaccurate.

@samueltlg

This comment has been minimized.

Show comment
Hide comment
@samueltlg

samueltlg Sep 24, 2018

Fantastic guys, that’s good news!

samueltlg commented Sep 24, 2018

Fantastic guys, that’s good news!

@shawnaxsom

This comment has been minimized.

Show comment
Hide comment
@shawnaxsom

shawnaxsom Sep 24, 2018

Contributor

Yes as @cmcclellen mentioned, we did find details that can help make some headway on the issue.

We confirmed that it isn't a conflict with other extension, though some of it does mimic behavior I was seeing with the Import Cost extension. I'm guessing there are multiple causes:

  • Inefficiencies painting with some video cards or drivers?
  • Something may be triggering reads from disk (for imports/intellisense?) when we insert text with vscode.commands.executeCommand('default:type', { text })?
  • Extra async actions are also competing with the event loop when awaiting in the handling of the text command override.

In relation to those issues, the main delays in our modeHandler.handleKeyEvent function stack involved:

  1. await vscode.commands.executeCommand('setContext', 'vim.mode', ... ), which I need to research. This was substantial, accounting for 50ms per key press, or about 65% of the processing time for each key press.
  2. handling of insertTextVSCode, which handles the TextEditor.insert that results in the default:type command to vscode. This accounted for an extra ~15ms, or about 20% of the processing time for each key press.
  3. Awaits in modeHandler.handleKeyEvent and modeHandler.handleKeyEventHelper, when something else must have been using the event loop. This accounted for about ~7ms, or about 10% of the time.

At least to start, I am going to look at optimizing use of (1) setContext. It is likely the easier fix, and commenting it out substantially improved performance for @cmcclellen. The (2) default:type command fix will be harder to diagnose and may involve support from the vscode team, unless there is some alternative, more efficient way to insert characters.

Contributor

shawnaxsom commented Sep 24, 2018

Yes as @cmcclellen mentioned, we did find details that can help make some headway on the issue.

We confirmed that it isn't a conflict with other extension, though some of it does mimic behavior I was seeing with the Import Cost extension. I'm guessing there are multiple causes:

  • Inefficiencies painting with some video cards or drivers?
  • Something may be triggering reads from disk (for imports/intellisense?) when we insert text with vscode.commands.executeCommand('default:type', { text })?
  • Extra async actions are also competing with the event loop when awaiting in the handling of the text command override.

In relation to those issues, the main delays in our modeHandler.handleKeyEvent function stack involved:

  1. await vscode.commands.executeCommand('setContext', 'vim.mode', ... ), which I need to research. This was substantial, accounting for 50ms per key press, or about 65% of the processing time for each key press.
  2. handling of insertTextVSCode, which handles the TextEditor.insert that results in the default:type command to vscode. This accounted for an extra ~15ms, or about 20% of the processing time for each key press.
  3. Awaits in modeHandler.handleKeyEvent and modeHandler.handleKeyEventHelper, when something else must have been using the event loop. This accounted for about ~7ms, or about 10% of the time.

At least to start, I am going to look at optimizing use of (1) setContext. It is likely the easier fix, and commenting it out substantially improved performance for @cmcclellen. The (2) default:type command fix will be harder to diagnose and may involve support from the vscode team, unless there is some alternative, more efficient way to insert characters.

@shawnaxsom

This comment has been minimized.

Show comment
Hide comment
@shawnaxsom

shawnaxsom Sep 25, 2018

Contributor

Good progress tonight on await vscode.commands.executeCommand('setContext', 'vim.mode', ... ).

I think that command is just letting vscode know what mode we are in, which appears to be used for our custom keybindings. It was executing every key press, and now I have it only executing when VimMode actually changes.

https://github.com/shawnaxsom/Vim/tree/feature/insert-mode-optimizations

Contributor

shawnaxsom commented Sep 25, 2018

Good progress tonight on await vscode.commands.executeCommand('setContext', 'vim.mode', ... ).

I think that command is just letting vscode know what mode we are in, which appears to be used for our custom keybindings. It was executing every key press, and now I have it only executing when VimMode actually changes.

https://github.com/shawnaxsom/Vim/tree/feature/insert-mode-optimizations

@cmcclellen

This comment has been minimized.

Show comment
Hide comment
@cmcclellen

cmcclellen Sep 25, 2018

Ran this branch locally and it definitely improved things quite a bit. @samueltlg If you can you may want to grab the above repo & branch and try it out.

For anyone wanting to try it out:

  1. clone the repo above
  2. checkout the feature/insert-mode-optimizations branch
  3. npm/yarn install
  4. open the directory in vscode
  5. Menu: Debug | Start / Start Without
  6. in the extension host version of vscode that pops up, open up the project you usually work on and see if it is better for you.

cmcclellen commented Sep 25, 2018

Ran this branch locally and it definitely improved things quite a bit. @samueltlg If you can you may want to grab the above repo & branch and try it out.

For anyone wanting to try it out:

  1. clone the repo above
  2. checkout the feature/insert-mode-optimizations branch
  3. npm/yarn install
  4. open the directory in vscode
  5. Menu: Debug | Start / Start Without
  6. in the extension host version of vscode that pops up, open up the project you usually work on and see if it is better for you.
@samueltlg

This comment has been minimized.

Show comment
Hide comment
@samueltlg

samueltlg Sep 26, 2018

@cmcclellen I have attempted to try this commit out in order to give some feedback, but the build phase upon the beginning of debugging is failing due to being unable to find the "gulp: build" task (the preLaunch task set in launch.json). I have tried changing names around here and there within launch.json and tasks.json (such as to "gulp" and "gulp: default", and variations without spaces), but the build isn't going ahead. Any idea?

samueltlg commented Sep 26, 2018

@cmcclellen I have attempted to try this commit out in order to give some feedback, but the build phase upon the beginning of debugging is failing due to being unable to find the "gulp: build" task (the preLaunch task set in launch.json). I have tried changing names around here and there within launch.json and tasks.json (such as to "gulp" and "gulp: default", and variations without spaces), but the build isn't going ahead. Any idea?

@shawnaxsom

This comment has been minimized.

Show comment
Hide comment
@shawnaxsom

shawnaxsom Sep 26, 2018

Contributor

@samueltlg Take a look at our contributing guide if you haven't yet, it has some steps to get going. Make sure you ran steps in there like npm install -g gulp-cli.

Let me know if that doesn't resolve it and I can assist further.

Contributor

shawnaxsom commented Sep 26, 2018

@samueltlg Take a look at our contributing guide if you haven't yet, it has some steps to get going. Make sure you ran steps in there like npm install -g gulp-cli.

Let me know if that doesn't resolve it and I can assist further.

@samueltlg

This comment has been minimized.

Show comment
Hide comment
@samueltlg

samueltlg Sep 26, 2018

@samueltlg Take a look at our contributing guide if you haven't yet, it has some steps to get going. Make sure you ran steps in there like npm install -g gulp-cli.

Let me know if that doesn't resolve it and I can assist further.

Ah, that would be it! I did not realise gulp-cli was not installed correctly on this machine. Thanks for that.

I managed to try it out, but I should mention that the build phase failed again due to not being able to find the 'vscode' module in the tsc phase(in fact it was not able to find the d.ts file of the vscode module due to a bug where it fails to be installed - see Microsoft/vscode#2810 ). So I had to insert a custom script in vim/vscode's package.json "pkgvars": "node ./node_modules/vscode/bin/install" and npm run it (alternatively I think you could npm run postinstall since it is the same script); and then run the debug/build afterwards.

I have noticed an improvement in typing latency, more so in smaller typescript files (I tried it in both 400 line and 3000 line typescript files) - but still an improvement overall. There is still a fairly large delay when moving the cursor up and down with j/k too. Unfortunately though, the delay in typing and cursor movement is still largely unpleasant and on this machine it is still overall unusable. Good progress, though.

Something else perhaps of noteworthiness. On every movement in normal mode and every key press in insert mode, I get this error in the console:

error: Remapper: insertModeKeyBindingsNonRecursive. Duplicate configuration. before=<C-f>. command=editor.action.extensioneditor.showfind. args=.

Sometimes it is 'before <C-y>' instead. This error occurred with and without custom mappings for Ctrl F and Y; strange that the error should occur on every key press in insert mode or action in normal mode.

samueltlg commented Sep 26, 2018

@samueltlg Take a look at our contributing guide if you haven't yet, it has some steps to get going. Make sure you ran steps in there like npm install -g gulp-cli.

Let me know if that doesn't resolve it and I can assist further.

Ah, that would be it! I did not realise gulp-cli was not installed correctly on this machine. Thanks for that.

I managed to try it out, but I should mention that the build phase failed again due to not being able to find the 'vscode' module in the tsc phase(in fact it was not able to find the d.ts file of the vscode module due to a bug where it fails to be installed - see Microsoft/vscode#2810 ). So I had to insert a custom script in vim/vscode's package.json "pkgvars": "node ./node_modules/vscode/bin/install" and npm run it (alternatively I think you could npm run postinstall since it is the same script); and then run the debug/build afterwards.

I have noticed an improvement in typing latency, more so in smaller typescript files (I tried it in both 400 line and 3000 line typescript files) - but still an improvement overall. There is still a fairly large delay when moving the cursor up and down with j/k too. Unfortunately though, the delay in typing and cursor movement is still largely unpleasant and on this machine it is still overall unusable. Good progress, though.

Something else perhaps of noteworthiness. On every movement in normal mode and every key press in insert mode, I get this error in the console:

error: Remapper: insertModeKeyBindingsNonRecursive. Duplicate configuration. before=<C-f>. command=editor.action.extensioneditor.showfind. args=.

Sometimes it is 'before <C-y>' instead. This error occurred with and without custom mappings for Ctrl F and Y; strange that the error should occur on every key press in insert mode or action in normal mode.

@shawnaxsom

This comment has been minimized.

Show comment
Hide comment
@shawnaxsom

shawnaxsom Sep 27, 2018

Contributor

@samueltlg Thanks for the feedback! Well I will get a PR up for the changes so far, and then we can keep this issue open and investigate further. If you would like to do a screen share at some point, I can help diagnose what else is causing the delay on your machine. Just reach out to me on our slack channel sometime after 5pm ET any day.

Contributor

shawnaxsom commented Sep 27, 2018

@samueltlg Thanks for the feedback! Well I will get a PR up for the changes so far, and then we can keep this issue open and investigate further. If you would like to do a screen share at some point, I can help diagnose what else is causing the delay on your machine. Just reach out to me on our slack channel sometime after 5pm ET any day.

@samueltlg

This comment has been minimized.

Show comment
Hide comment
@samueltlg

samueltlg Sep 28, 2018

@shawnaxsom No problem Shawn. And that would be great thank you; I'm sure it will help solve a few things since it is quite an extreme example (of slowness). I will try to get in touch with you via Slack next Monday or Tuesday evening, probably no later than 6pm ET if that's ok with you (I am five hours ahead); speak to you later!

samueltlg commented Sep 28, 2018

@shawnaxsom No problem Shawn. And that would be great thank you; I'm sure it will help solve a few things since it is quite an extreme example (of slowness). I will try to get in touch with you via Slack next Monday or Tuesday evening, probably no later than 6pm ET if that's ok with you (I am five hours ahead); speak to you later!

@shawnaxsom

This comment has been minimized.

Show comment
Hide comment
@shawnaxsom

shawnaxsom Sep 28, 2018

Contributor

@samueltlg That sounds good to me. A simple PR #3078 is up with the fix so far. We can fold any optimizations into there or wait for another PR if the changes will be larger.

Contributor

shawnaxsom commented Sep 28, 2018

@samueltlg That sounds good to me. A simple PR #3078 is up with the fix so far. We can fold any optimizations into there or wait for another PR if the changes will be larger.

@shawnaxsom

This comment has been minimized.

Show comment
Hide comment
@shawnaxsom

shawnaxsom Sep 29, 2018

Contributor

Note to all that the first PR was merged. Hopefully it alleviates much of the slowness for some users. Feel free to leave feedback after our next release.

I'll see what else we can identify during that screen share session this coming week.

Contributor

shawnaxsom commented Sep 29, 2018

Note to all that the first PR was merged. Hopefully it alleviates much of the slowness for some users. Feel free to leave feedback after our next release.

I'll see what else we can identify during that screen share session this coming week.

@enricribas

This comment has been minimized.

Show comment
Hide comment
@enricribas

enricribas Oct 4, 2018

foldfix: true == very slow

enricribas commented Oct 4, 2018

foldfix: true == very slow

@JesseObrien

This comment has been minimized.

Show comment
Hide comment
@JesseObrien

JesseObrien Oct 12, 2018

Awesome work! Thanks for investigating this. I've tried it a bunch the last week and found no issues anymore.

JesseObrien commented Oct 12, 2018

Awesome work! Thanks for investigating this. I've tried it a bunch the last week and found no issues anymore.

@shawnaxsom

This comment has been minimized.

Show comment
Hide comment
@shawnaxsom

shawnaxsom Oct 12, 2018

Contributor

Thanks for the feedback @JesseObrien!

Someone else on our Slack channel mentioned it is still slow for them unfortunately, but I am glad to know it solved the issue for some individuals.

@samueltlg or others, please reach out on Slack if you would still like to screen share to investigate further.

Contributor

shawnaxsom commented Oct 12, 2018

Thanks for the feedback @JesseObrien!

Someone else on our Slack channel mentioned it is still slow for them unfortunately, but I am glad to know it solved the issue for some individuals.

@samueltlg or others, please reach out on Slack if you would still like to screen share to investigate further.

@samueltlg

This comment has been minimized.

Show comment
Hide comment
@samueltlg

samueltlg Oct 12, 2018

@shawnaxsom - my dearest apologies! I have had every intention of reaching you over Slack, but I have been incredibly busy over the past two weeks. As soon as I get a spare couple of hours I shall be in contact on a day 5pm ET or later. I have also been using vscode vim over the past couple of weeks, even with the moderate delay in typing and sometimes movement. But as we all know, vim is so bloody useful and fun to use, that (at least for me) it’s worth having long delays in your text rendering!

samueltlg commented Oct 12, 2018

@shawnaxsom - my dearest apologies! I have had every intention of reaching you over Slack, but I have been incredibly busy over the past two weeks. As soon as I get a spare couple of hours I shall be in contact on a day 5pm ET or later. I have also been using vscode vim over the past couple of weeks, even with the moderate delay in typing and sometimes movement. But as we all know, vim is so bloody useful and fun to use, that (at least for me) it’s worth having long delays in your text rendering!

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