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

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:

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

This particular issue is affecting many extensions. Those of us who like the excellent auto-completion on vscode and the powerful features of a modal editor like vim find this a deal breaker 😦

Please give this issue some love ❤️ Thanks!

Is there anything I can do to assist with this?

I apologise profusely for letting this issue go dead by not responding a couple of months ago; I had a prolonged emergency situation and never got round to testing and reporting back on the effects of the provided minimal extension. I was reminded by the issue reference yesterday and have got round to trying it out.

Big surprise. The simple extension provided incurs very-almost the same performance penalty as VSCodeVim (with Vim and all other extensions disabled, of course). This came as a shock to me, because I did think that perhaps it was VSCodeVim after all. I have made extra sure that there is nothing else interfering. The basic ‘hello world’ predictably has no effect on typing, but simply adding the few lines of code to override the type command and execute the default type command within, has a very large effect on rendering/performance. As you say @alexandrudima, it is perhaps due to the frame being missed and the rendering occurring at the next frame.

I have not attempted to apply the diff to vscode for measuring typing (rendering) latency via going through the extension host; if this would be helpful, I could report back on this. Unremarkably, too, the measured extension host latency is around 2-3ms. Quite the shock indeed… if there is anything I can do to assist and test, please do let me know.

@JuanQuiro Hi, Jump’s author here, you can paste the following config into your VSCode settings.json:

{
  "extensions.experimental.affinity": {
    "wenfangdu.jump": 1
  }
}

I was curious to dig a bit deeper. The larger times are mostly because the frame is missed and the painting occurs at the next frame (and the times above measure the elapsed time from keypress until the paint occurs), not due to latency. To validate this, I have built an action that tests the latency of going to the extension host process, as well as the throughput. It will come out with tomorrow’s insiders

e.g. Developer: Measure Extension Host Latency

Roundtrip latency: 0.690ms
Up: 586.9 Mbps
Down: 487.2 Mbps

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.

FWIW:

• I tried this, for vscode-vim
• It seemed worse — typing lots of characters quickly on opening VS Code caused some to end up in front of the cursor
• Removing the setting from settings.json didn’t seem to remove it — changing the vim extensions’ settings in settings.json didn’t seem to impact its behavior. I was still seeing output in Output -> Window that vim was in a different process after running “Reload Window” (also after quitting and restarting VS Code)
• I ended up wiping ~/Library/Application Support/Code, which then took a while to restore settings
  • Possibly I should have tried restarting the machine, if it was in a process outside VS Code?

So — I wouldn’t recommend trying this unless you really need it.

If this is wrong, very happy to be corrected by someone knowledgeable about the code — clearly one person having a bad experience shouldn’t be weighed that much.

@samueltlg I also wondered what is the overhead of going through the extension host for typing, so I applied the following diff to vscode to measure it:

diff --git a/src/vs/editor/browser/controller/textAreaInput.ts b/src/vs/editor/browser/controller/textAreaInput.ts
index 7ccf0e99d2..4700cba17f 100644
--- a/src/vs/editor/browser/controller/textAreaInput.ts
+++ b/src/vs/editor/browser/controller/textAreaInput.ts
@@ -54,6 +54,8 @@ const enum TextAreaInputEventType {
 	blur
 }
 
+export let lastKeyDownTime: number;
+
 /**
  * Writes screen reader content to the textarea and is able to analyze its input events to generate:
  *  - onCut
@@ -125,6 +127,8 @@ export class TextAreaInput extends Disposable {
 		this._nextCommand = ReadFromTextArea.Type;
 
 		this._register(dom.addStandardDisposableListener(textArea.domNode, 'keydown', (e: IKeyboardEvent) => {
+
+			lastKeyDownTime = Date.now();
 			if (this._isDoingComposition &&
 				(e.keyCode === KeyCode.KEY_IN_COMPOSITION || e.keyCode === KeyCode.Backspace)) {
 				// Stop propagation for keyDown events if the IME is processing key input
diff --git a/src/vs/editor/browser/viewParts/lines/viewLine.ts b/src/vs/editor/browser/viewParts/lines/viewLine.ts
index 1467d539a3..b17998876e 100644
--- a/src/vs/editor/browser/viewParts/lines/viewLine.ts
+++ b/src/vs/editor/browser/viewParts/lines/viewLine.ts
@@ -16,6 +16,7 @@ import { CharacterMapping, ForeignElementType, RenderLineInput, renderViewLine }
 import { ViewportData } from 'vs/editor/common/viewLayout/viewLinesViewportData';
 import { InlineDecorationType } from 'vs/editor/common/viewModel/viewModel';
 import { HIGH_CONTRAST, ThemeType } from 'vs/platform/theme/common/themeService';
+import { lastKeyDownTime } from 'vs/editor/browser/controller/textAreaInput';
 
 const canUseFastRenderedViewLine = (function () {
 	if (platform.isNative) {
@@ -213,6 +214,8 @@ export class ViewLine implements IVisibleLine {
 			return false;
 		}
 
+		console.log(`${Date.now() - lastKeyDownTime}ms since last input -- ${renderLineInput.lineContent}`);
+
 		sb.appendASCIIString('<div style="top:');
 		sb.appendASCIIString(String(deltaTop));
 		sb.appendASCIIString('px;height:');

Please note that the rendering occurs at the next animation frame, so it is delayed until Electron considers it would be a good idea for us to render, i.e. the times below do not indicate the time it takes to interpret the typing, but indicate the elapsed time from when the keydown was first received until a line was painted:

• typing “hello world” without the extension:

38ms since last input -- h
7ms since last input -- he
7ms since last input -- hel
5ms since last input -- hell
4ms since last input -- hello
5ms since last input -- hello 
5ms since last input -- hello w
5ms since last input -- hello wo
4ms since last input -- hello wor
3ms since last input -- hello worl
10ms since last input -- hello world

• typing “hello world” with the extension:

27ms since last input -- h
15ms since last input -- he
15ms since last input -- hel
11ms since last input -- hell
19ms since last input -- hello
29ms since last input -- hello 
20ms since last input -- hello w
24ms since last input -- hello wo
12ms since last input -- hello wor
27ms since last input -- hello worl
12ms since last input -- hello world

Although non-negligible, the latency of going to the extension host process and back is somewhere in the 10-15ms ballpark, which is still fast enough to make typing feel buttery smooth.

TL;DR I don’t think there is an issue with VS Code here…