Windows Terminal input is as slow as rubber cement

[wjk]

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]

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]

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]

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]

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]

@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]

@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]

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

[riverar]

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]

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]

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]

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]

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]

+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]

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]

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]

@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.