Overriding the default 'type' command and then calling the default 'type' command results in significantly slower execution time

• VSCode Version: 1.27.1
• OS Version: Windows 10 1809
• Machine processor: AMD A8-4555M APU Quad core clocked at 1.6GHz
• Graphics card: AMD Radeon HD 7600G

Does this issue occur when all extensions are disabled?: Yes (Aside from VSCodeVim - where the potential problem in the extensions API has been detected)

Steps to Reproduce:

1. Override the ‘type’ command with vscode.commands.registerCommand
2. Call the default ‘type’ command instead of the custom command
3. Note the difference in execution time in calling vscode.commands.executeCommand('type', ...) when no custom type command has been registered, vs. calling vscode.commands.executeCommand('default: type', ...) (when a custom command has been registered/is overriding the default ‘type’ command). On my machine, the difference in execution time is consistently an order of magnitude (roughly 20ms vs 200ms) larger every time the executeCommand(‘default: type’, …) is called after overriding.

I have included some of my machine details here just-in-case - although I do doubt that they play any part in the issue here.

One of VSCode’s most popular plugins, VSCodeVim/Vim, has an issue experienced by a fair share of the VSCodeVim community, as can be seen in an issue raised over a year ago in their repo - VSCodeVim/Vim#2021. Typing in an editor window whilst this plugin is enabled results in an unbearably slow character render time, for a range of slower (and perhaps sometimes slighty-faster-than-slow) machines. During a screen-share a little while ago with @shawnaxsom, a contributor to the VSCodeVim community, we boiled the problem down to the ‘type’ command being overridden, and then having the default type command executed afterwards. For example, from my understanding of the VSCodeVim extension, the ‘type’ command is overridden like so:

vscode.commands.registerCommand('type', async ...

The default ‘type’ command is then called when needed, with code like this:

await vscode.commands.executeCommand('default:type', { text });

We measured the time taken for an ordinary (non-overridden) execution of the type command (which was roughly 20ms on my machine), vs. then calling ‘default: type’ command, which was always roughly 10x slower. Even though I am not familiar with the extensions API, this is puzzling, since these two calls should be doing exactly the same thing, yet calling executeCommand('default: type', ...) results in a much slower execution time of the default type command. I guess it has been an assumption that the source code in the VSCodeVim extension has been responsible for the severe typing slowness (or, it has only been occurring on slow machines, since it does not occur for everyone using the extension), but our screenshare led us to the conclusion that it appears to be this part of the extensions API which seems to be responsible. I imagine, also, that the much-slower execution time also occurs on faster machines, but it is simply not noticeable due to the fact that the faster processing/graphical power prevents the comparably slower call to the ‘type’ command being made visible rendering-wise. Even though it shouldn’t matter, It is perhaps worth mentioning too, that even if the overridden (type) command is doing minimal work, as far as I know (I think we also tested this), the significant execution time difference still occurs.

[alexdima]

In our latest Insiders Build, we have added a new experimental setting that would allow to execute the vim extension in a dedicated extension host process.

Configure the following in your settings.json and then reload window or restart:

"extensions.experimental.affinity": {
	"vscodevim.vim": 1,
	"asvetliakov.vscode-neovim": 1
},

---

You can double check that vim is loaded in a separate process using F1 > Developer: Show Running Extensions:

[johnfn]

The number of thumbs up on this issue is deceptive. It’s the second most highly upvoted issue for VSCodeVim: https://github.com/VSCodeVim/Vim/issues/2021