Vim: Improve performance

[Chillee]

There's a bunch of places we could improve performance.

• [ ] Don't redraw during repeated insertions
• [ ] Don't redraw for every cursor in multicursor
• [ ] Don't redraw during undo
• [ ] Don't redraw during macros
• [ ] Offload more things to neovim?
• [ ] There seems to be a delay in commands like o in switching from normal mode to insert mode. I'm not sure whether this is a visual issue or an actual delay.

[theprash]

For ages I thought that VS Code was quite a laggy editor. I just tried disabling VSCodeVim and found it became much better!

The lag seems noticeable for any edits and movements. It's even noticeable during normal typing in insert mode.

[gadkadosh]

One extremely expensive action seems to be the really nice status bar color feature.
Typing 'i123' and then even just a few '.', results in ridiculously slow performance. Without the color changing it's way faster.

[Chillee]

@gadkadosh About that... It turns out that changing the settings and waiting for the settings to change is a very expensive operation.

How do you feel about us just removing it @xconverge ? I think we should at least put a performance warning, but it seems like a good idea to remove ways that users can shoot themselves in the foot with regards to performance.

[xconverge]

Users beg for the feature, vscode implements a crippled API and we add the feature, then the feature doesn't work great.

We already state this in the readme:

Notes: Experimental feature, currently due to VSCode API limitations, this function MUST modify settings.json in the workspace. This causes a slight amount of latency and a constant changing diff in your working directory. Issue #1565

https://github.com/VSCodeVim/Vim#vimstatusbarcolorcontrol

I think we should just leave it as is and focus on other performance issues for now.

[neg3ntropy]

I was using the extension on medium size ts project and had to disable it due to extreme lagging in insert mode. Sometimes, especially when working with mismatched parentheses or unclosed format strings the whole editor just halted completely.

I don't think this issue belongs to one of the proposed improvements so far. There seem to be some really ugly bottlenecks somewhere.

PS vscode 1.18.1 made things even worse than 1.17

[Chillee]

@soulrebel Sounds like it might be this? https://github.com/VSCodeVim/Vim/issues/2176

[HybridEidolon]

If these performance hot spots are still an issue, I have noticed that when the Power Settings on Windows 10 (a Surface Book 2 specifically) are set to anything other than "Best Performance," typing and interacting with the editor becomes incredibly slow (upwards of 50ms per key event handled) and each input gets buffered. This happens whether or not VSCode is running under system bitmap DPI scaling or application-driven Hi-DPI support. Seems like the redraws are the culprit, but I am having trouble navigating the perf tools as it gets _very_ slow when profiling this particular use case.