Integrated terminal poor performance on WSL 2 (laggy)

[jasonwilliams]

Version: 1.47.0-insider (system setup)
Commit: 7e4cc2c435927e5a2845897961a2af10ee7f784d
Date: 2020-06-12T06:03:53.183Z
Electron: 7.3.1
Chrome: 78.0.3904.130
Node.js: 12.8.1
V8: 7.8.279.23-electron.0
OS: Windows_NT x64 10.0.19041
OS Version: Windows 10 Pro

Steps to Reproduce:

1. Open a project VSCode native to windows
2. use the terminal
3. Open another (or the same) project in WSL 2 (using the WSL2 extension not just typing wsl in the terminal)
4. use the terminal again..
5. If you have Windows Terminal installed, compare the performance between that and the integrated terminal (with a project in WSL 2)

Does this issue occur when all extensions are disabled?: Yes

The integrated terminal seems to be a bit slow when using WSL2.
I have zsh installed but i don't think its that because Windows Terminal is snappy and works fine in the same directories, the issue is only in the integrated terminal.

It isn't super slow, but it does have a laggy feel.
The issue doesn't appear to be with WSL as other terminals outside of VSCode are fine.

[Tyriar]

There is a know problem with speed here: #74620, if it's rendering being slow you could try using the setting "terminal.integrated.rendererType": "experimentalWebgl"

/duplicate

[jasonwilliams]

@Tyriar I will try that, thanks

[jasonwilliams]

@Tyriar switching to experimentalWebgl made no difference, are you sure the 2 issues are related? This only happens on WSL so I don’t think it’s a rendering problem

[Minituff]

The VSCode terminal is also running slow for me in the WSL2 terminal.
When I use the new Windows terminal then WSL2 is speedy.
So, I do think its VSCode related.

[Tyriar]

Can you open dev tools (Help > Toggle Developer Tools), and do a performance profile (Performance tab, hit record button) of the lagginess, save and upload that here?

[jasonwilliams]

wsl-windows-profile.zip

@Tyriar I didn't see anything obvious between each profile, but there is a lag on the WSL one, for example, just typing my name feels slower than the native (powershell) version

[jasonwilliams]

keybash.zip

This one is more interesting, it looks like the WSL version generates less frames than the windows version, maybe this could be contributing to the laggy feel

[Tyriar]

So from those profiles everything seems to be working fine, the WSL ones even seem better as expected as they're not being routed through pty emulation (conpty). If it's purely input latency that wouldn't show up in the profiles, my only explanation for what you're seeing is that the communication bridge between Windows and WSL2 on your machine is slower than normal which would slow the entirety of VS Code.

Not sure what I can do about this unless I can repro it unfortunately and I use a WSL2 remote every day and it's always been faster than in Windows.

[jasonwilliams]

@Tyriar i was also surprised by the performance output. I agree i think maybe its an input latency issue with the communication bridge, are there any tools for debugging this (or even confirming that's the case)?

interestingly enough i don't find the whole of VSCode slow (maybe it is slower and i haven't noticed) just when I type in the integrated terminal

[Tyriar]

@jasonwilliams if my theory is true, the same latency would happen when you open or save a file, not when you type in the editor though. I'd think such latency would be much harder to perceive though than keystroke to character on screen. I don't know of any way to debug this, maybe @aeschli might know?

[jasonwilliams]

Aside: Windows Terminal seems ok and faster than the integrated terminal in VSCode, so I'm not sure if its a "Windows OS" issue. Opening and closing files is pretty fast (if that helps)

[jasonwilliams]

pings @aeschli

[aeschli]

Maybe run it out of sources and add log statements? I would check if it reproduces with the TestResolver. Otherwise you need WSL out-of-sources setup (setup is described on our (internal) remote wiki (@Tyriar can access))

[jasonwilliams]

What’s the testResolver? And what’s the out of sources setup? @Tyriar does this make sense to you?

[thijsputman]

Below two screen-captures that hopefully demonstrate what @jasonwilliams is describing:

Remote-WSL (WSL2)

"regular"

Captured on the same machine, same installation of VS Code (1.48.0 – same extensions enabled). The only difference is that one is running "direct" and the other via the Remote-WSL extension.

Had my password manager type out the text; animated GIF captured at 60 FPS. The captures don't fully do it justice ("in person" it feels much worse), but I hope it helps to get "the picture" across... 🙂

I've been having some related odd behaviours as well:

Multiple times per hour, VS Code running remotely on WSL2 stops processing my keyboard input for a couple seconds. It appears to hang, but the caret keeps blinking and the UI remains responsive (i.e. I can click open menus). After a couple seconds, all input is spit out in one go...
Additionally, sometimes when trying to open a folder in the "Explorer", I get a little spinning disc for a couple seconds until the contents of the directory are displayed (similar behaviour sometimes occurs when trying to open a file; wait a couple seconds while looking at a blue "progress bar").

All seems to point to some kind of issue in the connection between VS Code and the "remote" WSL?

I'm using WSL2 quite actively for other stuff and haven't noticed any strange behaviour when interacting with it directly (through Windows Terminal) or while using Docker to, for example, run test-suites.

Recently got a new laptop, so I'm not sure if it's related to a specific version of VS Code, something I did with my Windows-installation or something specific to the hardware of this device...

[jasonwilliams]

Ahh @thijsputman thank you very much for that, I’m glad it’s not just me going mad. I tried to find a way to show this but couldn’t so I’m happy you’ve done that.

@Tyriar @aeschli what @thijsputman is describing is what I experience also, and as he’s said the comparison gifs don’t do it justice.

[thijsputman]

Ahh @thijsputman thank you very much for that, I’m glad it’s not just me going mad.

My pleasure!

Had been blaming my video card driver for the sluggishness (and was thus on a wild goose chase attempting to resolve that issue). Very happy to come across your bug report.

Just set up a clean copy of Ubuntu on WSL2 and that exhibits the same issue. It doesn't appear to be caused by any specific modifications made inside the WSL2 distro...

[thijsputman]

Ran a couple more tests:

Connecting to WSL2 via SSH exhibits the same issue; using SSH to connect to another device (a Raspberry Pi on the local network) appears laggy too.

Interestingly, the problems seems to be purely input-related: Observing the output of cmatrix shows no stutter, no lag, whatsoever.

[jasonwilliams]

Looks like it was raised before microsoft/vscode-remote-release#1732 but it didn't go anywhere

[jasonwilliams]

Maybe run it out of sources and add log statements? I would check if it reproduces with the TestResolver. Otherwise you need WSL out-of-sources setup (setup is described on our (internal) remote wiki (@Tyriar can access))

@Tyriar @bpasero are you able to help us with this? or copy over the internal wiki details?

[jasonwilliams]

I'm not sure if this is the location the terminal is used, but it could be worth logging here and building from source.

vscode/src/vs/workbench/contrib/terminal/node/terminalProcess.ts

Lines 231 to 237 in f74e473

	public input(data: string): void {
	if (this._isDisposed || !this._ptyProcess) {
	return;
	}
	this._logService.trace('IPty#write', `${data.length} characters`);
	this._ptyProcess.write(data);
	}

[josalhor]

I am also facing the same issue.

Moreover, I have found that the terminal lags significantly on certain outputs.

Example: awk 'BEGIN { for(i = 0; i < 10000; i++) printf "%c","0" }' Will provide significant freezes on scrolling. Changing the 10000 for 100000 will straight up freze VS code entirely. experimentalWebgl doesn't fix this issue.

[Darsh2987]

I’m affected by this aswell. It’s only slow when in WSL mode.

[josalhor]

Example: awk 'BEGIN { for(i = 0; i < 10000; i++) printf "%c","0" }' Will provide significant freezes on scrolling. Changing the 10000 for 100000 will straight up freze VS code entirely. experimentalWebgl doesn't fix this issue.

I want to report that on VSCode 1.52 I can no longer reproduce this example of my previous comment. I know that it can still crash in some circuntances, but the performance has certainly improved.

[Grelot]

I am affected with this issue too. WSL is slow within the terminal of visual code while WSL alone is running well outside visual code.

[AleKrabbe]

Any updates on this? I'm facing the same issue.

[julien-conan]

Same (lame) issue here.

[jasonwilliams]

Windows 11 Pro
VSCode 1.61.0-insider

Terminal still has a longer latency in VSCode than in Windows Terminal on WSL. This issue is still apparent.
Terminal is the only thing with lag when using WSL, everything else (editor, filesystem etc) works fine. There's clearly something running causing lag on each keypress.

[Tyriar]

@aeschli I believe this is related to the remote protocol, not the terminal. Also, there's this closely related SSH issue https://github.com/microsoft/vscode-remote-release/issues/5695

[aeschli]

@Tyriar Any pointers and measurements to what is slow?

[Tyriar]

I believe this is a duplicate of https://github.com/microsoft/vscode-remote-release/issues/5695

[jasonwilliams]

I believe this is a duplicate of microsoft/vscode-remote-release#5695

Or that issue is a duplicate of this? As it was only opened 22 days ago, and this has been up for well over a year, with far more information in it

[Tyriar]

Since this report is about the terminal specifically let's track in #135644