Windows Terminal input is as slow as rubber cement

wjk commented 2 years ago

Windows Terminal version

1.11.2921.0

Windows build number

10.0.22000.318

Other Software

My environment:

VMware Fusion version 12.1.1
macOS Monterey 12.0.1
2.2 GHz 6-Core Intel Core i7 CPU (as reported by About This Mac)
16 GB host memory

The virtual machine specs:

4 cores (the Windows 10 minimum)
8 GB RAM

Steps to reproduce

I am currently running the Visual Studio installer in this VM, placing it under heavy load (100% CPU utilization in Task Manager). If I type anything when the machine is this loaded, the input response time is unusably slow. It is so slow that if I alt-tab away from the terminal, I worry that my inputs might be sent to another program because the terminal hasn't processed them yet. Not being able to alt-tab away after typing a command is a serious productivity blocker for me.

Expected Behavior

The input latency being as fast as any other program on the VM at this heavy a load. (Try filling out a bug report form in Microsoft Edge under these circumstances, like I'm doing. The input latency there is as fast and as responsive as I expect.)

Actual Behavior

Enough time for me to enter a complete command line before the first character appears onscreen. The arrow keys, Backspace, and Ctrl+C are also processed this slowly. (I am a fast typist, but my hand-eye coordination isn't what it used to be; I make many typos while writing text.)

zadjii-msft commented 2 years ago

Hmmm. This might be a core input site bug. That's at least my only theory.

Is typing in the vintage console conhost.exe reasonably responsive?
What about typing in something like the Xaml Controls Gallery, or maybe even the Mail app?

Just trying to narrow down the problem space here. I'm not sure of any other good Xaml Islands applications that have text boxes that we could use for a comparison 😕

DHowett commented 2 years ago

This might be fallout from some of the responsiveness work we've done in Windows 11. Terminal is considered a foreground application, but the console application it is hosting isn't. This may cause some trouble.

If you try to make a text selection when it's bogged down, does that respond at a normal speed? That may help us determine which part of the pipeline is falling down.

jpage-godaddy commented 2 years ago

I don't know if this is the exact same thing, but I'm experiencing strangeness when it comes to keyboard input. My computer can get into a state where I get slowness of keyboard input and sometimes repeated characters. Details:

The problem only happens with my wireless keyboard.
The problem isn't there on a fresh reboot; it seems to start happening after some time.
Turning my wireless keyboard on/off does not help.
Restarting the terminal app seems to briefly help but the problem returns quickly.
My wireless keyboard doesn't cause this issue in other apps; it's only this terminal app.
My non-wireless laptop keyboard doesn't have this issue.
It happens for wsl and powershell, though it's much worse in wsl.
It does not happen in conhost.exe.
Text selection is not experiencing the lag.

I'm baffled; sorry to hijack if this is not the same issue as yours @wjk...

wjk commented 2 years ago

This might be fallout from the Windows 11 "Foreground Boost" work to make foreground apps more responsive. Terminal is considered a foreground application, but--critically--the console application it is hosting is NOT.

Yep, that’s exactly what’s happening. I can select text and manipulate the app just fine while the input is lagging badly. Is there any way we can make Terminal able to exempt its child process tree from Foreground Boost?

zadjii-msft commented 2 years ago

@DHowett I'm having a hard time finding anything on Foreground Boost. You think this is something we'll need to follow up with an internal deliverable to get Terminal/conpty sessions accounted for correctly? Or is there and API we can use?

riverar commented 2 years ago

@wjk If you can reliably reproduce this on newer builds of Windows (22489 and higher), can you try reproducing without this boosting enabled? You can fiddle with the feature store to run this test (i.e. vivetool addconfig 36557215 2 and reboot). Don't run this on your main PC and other assorted warnings go here.

For Microsoft: See https://task.ms/36557215 or perhaps look up PriClassNoFgBoost velocity. Should be a good start for your investigation.

wjk commented 2 years ago

After running vivetool, the Terminal is just as responsive as I would expect it to be given the CPU load.

riverar commented 2 years ago

I guess that confirms @DHowett's suspicions this is related to new boosting behavior. Thanks for the super quick turnaround. Now to squeeze Microsoft for official docs/guidance... 🤣 (To undo your changes, run vivetool delconfig 36557215 2 and reboot.)

zadjii-msft commented 2 years ago

There might be a regression in the OS we've discovered here. I've filed MSFT:37406950 tracking this internally on the kernel team to investigate what's going on here. We'll keep you posted with anything we hear back! (which may be a while with the holidays)

DJankauskas commented 2 years ago

Is there any movement on this issue? On Windows 11 22H2 I experienced extreme input lag in both Windows Terminal and Visual Studio Code, at least on battery power. Downgrading back to 22H1, along with the viveconfig tip above, seemed to solve the problem, but viveconfig did not help in 22H2. The lag made Terminal downright unusable, and I think it needs to be prioritized before developers are upgraded to 22H2. Personally I found the experience frustrating enough that I was thinking of switching to Linux or MacOS if I couldn't solve the problem.

paulboco commented 2 years ago

I was having the same issue. The issue stopped when I removed the .aws and .azure symlinks from my home directory. Don't know if this is related. Edit: I spoke too soon. After an hour the sluggish behavior returned.

chrisfcarroll commented 2 years ago

My environment:

Windows 10 21H2
Dell Precision 3551 16GB Core i7 and 'slow as rubber cement' seems a fair description. conhost.exe and other apps are fine.

stephenmartindale commented 2 years ago

+1 on Windows 10 10.0.19044; wt says it's 1.15.2874.0 after I finally worked out how to call up the about dialogue.

I first noticed this with keyboard shortcuts like ctrl+c which are extremely slow – unusably slow, in fact. In some shells – git bash like – it's "slow as in minutes", not just "slow as in laggy".

And, yes, I, too, have noticed that the integrated terminal in vs code exhibits similar behaviour. conhost terminals do not.

arymkus commented 1 year ago

Same issue, awkwardly slow input while typing Windows 11 21H2 OS build 22000.2538 terminal 1.18.2822.0

GitHub's mintty git bash and vscode's git bash work just fine.

rickgladwin commented 8 months ago

Same issue, very laggy (several seconds) when typing on the command line. The same issue wasn't happening when using Powershell. To reproduce:

open Windows Terminal
command wsl (Windows Subsystem for Linux)
open an ssh session to a remote server with localhost port forwarding (ssh -L <local port>:<remote host>:<remote port> <user>@<remote host)
type commands in the remote shell OR use vim in the remote shell (vim lag is even worse)

zadjii-msft commented 8 months ago

@rickgladwin Can you go chime in over at #16861? I think there's possibly a more recent regression in this space that might be relevant.

pryorda commented 7 months ago

@zadjii-msft These versions did not fix the issue for me.

SpBills commented 3 weeks ago

Can confirm this is still a problem. Using Alacritty right now because wt is unbelievably slow.

zadjii-msft commented 3 weeks ago

@SpBills Can you share your Terminal & OS Version?

Honestly this thread might just need to be closed in favor of newer information. I'm worried it's gotten too piled on with a variety of similar symptoms of different root causes.

The renderer has been dramatically rewritten (twice) since 1.11. So perf there shouldn't be an issue anymore?
Is the settings UI also laggy in this scenario? Or just the commandline? That would help ID if this is a foreground boost thing or not
does it only repro when the CPU is under load? or does it repro always?
being on 1.23 (the most recent terminal builds) will probably get the most consistent results

chrisfcarroll commented 3 weeks ago

@zadjii-msft — it could be that the widespread cause is that the Windows Store versions of Terminal are (or were last time I installed) years out of date. That would affect many of us on locked-down corporate desktops.

If so, is there some better place than here to get that addressed?

DHowett commented 3 weeks ago

@chrisfcarroll FWIW, the store version of Terminal updates 1-2 weeks after we make a release on GitHub. The current Store version is 1.21.2911.0, which is the latest stable (it came out two weeks ago.)

corporate

That could explain it. Some enterprises do restrict the frequency of updates or the versions available on update.

It is for exactly this reason that we encourage everybody filing bugs or resurrecting years-old bugs to include their version information. That’s why it’s one of the items in the bug template.

As for getting that addressed: I'd recommend talking to your local IT administrator. ☹

microsoft / terminal