starred/terminal
1
0
Fork 0
mirror of https://github.com/microsoft/terminal.git synced 2026-02-04 05:35:20 +00:00
Code Issues 19.0k Packages Projects Releases 20 Wiki Activity

Terminal output speed improvement #11748

New Issue
Closed
opened 2026-01-31 02:56:18 +00:00 by claunia · 6 comments
claunia commented 2026-01-31 02:56:18 +00:00
Owner
Copy Link

Originally created by @NeKJ on GitHub (Dec 9, 2020).

Following the completion of #1064, which greatly sped up the performance of drawing and rendering of Windows Terminal (yehey!! kudos to the WT team), I am opening this, to point out, that there is still some room for improvement left.

WT still has a noticeable delay in rendering, albeit very, very small, but easy to spot and occurs very often. Despite WT being consider "fast", especially compared to CMD or other slow terminals, it still falls a bit short compared to almost all other terminals for other platforms (i.e. linux: konsole, urxvt, lxterm plus many more). Is hard to say exactly how slower it is, nevertheless it is plainly evident just by typing and using it on a daily basis. And especially if you use it along side another faster terminal (i.e. putty).

I prepared a simple comparison betwen PuTTY and WT, both running natively on the same machine, win10 x64, and both connected through the same network to ssh to a linux VM, so the comparison only demonstrates the raw rendering performance of the terminals.

Left is PuTTY Release 0.71 and at the right is Windows Terminal v1.4.3243.0
comparison-putty-vs-wt-big-ls

Notice how PuTTY draws/renders the output of the ll (alias of ls -l) command instantaneously and how Windows Terminal does it with a slight, but still clearly visible, delay.

With a bigger output, this becomes even more evident to the user. Here is the same comparison with an ls output of a directory with more files, and therefore more data to draw and render:
comparison-putty-vs-wt-big-ls-scrolling

Take note that this animation is 30FPS, whereas the real display runs at 60/120/240fps (depending the monitor), which makes it even more evident when experiencing it first hand.

So I petition and propose to go on and do whatever is necessary, in order to reach the same snappy performance as PuTTY (and other fast terminals).

I'll be glad to help, if you need any testing, or even coding (I am a developer too).

Originally created by @NeKJ on GitHub (Dec 9, 2020). Following the completion of #1064, which greatly sped up the performance of drawing and rendering of Windows Terminal (yehey!! kudos to the WT team), I am opening this, to point out, that there is still some room for improvement left. WT still has a noticeable delay in rendering, albeit very, very small, but easy to spot and occurs very often. Despite WT being consider "fast", especially compared to CMD or other slow terminals, it still falls a bit short compared to almost all other terminals for other platforms (i.e. linux: konsole, urxvt, lxterm plus many more). Is hard to say exactly how slower it is, nevertheless it is plainly evident just by typing and using it on a daily basis. And especially if you use it along side another faster terminal (i.e. putty). I prepared a simple comparison betwen PuTTY and WT, both running natively on the same machine, win10 x64, and both connected through the same network to ssh to a linux VM, so the comparison only demonstrates the raw rendering performance of the terminals. Left is _PuTTY Release 0.71_ and at the right is _Windows Terminal v1.4.3243.0_ ![comparison-putty-vs-wt-big-ls](https://user-images.githubusercontent.com/5416165/101696324-a1d03800-3a7e-11eb-9307-b412504b8614.gif) Notice how PuTTY draws/renders the output of the _ll_ (alias of ls -l) command **instantaneously** and how Windows Terminal does it with a slight, but **still** clearly visible, delay. With a bigger output, this becomes even more evident to the user. Here is the same comparison with an ls output of a directory with more files, and therefore more data to draw and render: ![comparison-putty-vs-wt-big-ls-scrolling](https://user-images.githubusercontent.com/5416165/101696326-a399fb80-3a7e-11eb-8c15-1f52b9bd3296.gif) Take note that this animation is 30FPS, whereas the real display runs at 60/120/240fps (depending the monitor), which makes it even more evident when experiencing it first hand. So I petition and propose to go on and do whatever is necessary, in order to reach the same snappy performance as PuTTY (and other fast terminals). I'll be glad to help, if you need any testing, or even coding (I am a developer too).
claunia added the Issue-FeatureResolution-Duplicate labels 2026-01-31 02:56:18 +00:00
claunia commented 2026-01-31 02:56:19 +00:00
Author
Owner
Copy Link

@zadjii-msft commented on GitHub (Dec 10, 2020):

You know, @miniksa and @lhecker were working on this for a while. They got a huge performance boost, by basically draining the output as fast as possible into a buffer, which resulted in some ridiculous performance gains. There was a bit of a tradeoff between memory usage and perf IIRC. If an app produced a ridiculous amount of output, the options were to either buffer all of it, which would be a ton of memory usage, or not buffer it, and eventually the perf gain would go away.

I'm not totally sure where that ended up landing.

@zadjii-msft commented on GitHub (Dec 10, 2020): You know, @miniksa and @lhecker were working on this for a while. They got a _huge_ performance boost, by basically draining the output as fast as possible into a buffer, which resulted in some ridiculous performance gains. There was a bit of a tradeoff between memory usage and perf IIRC. If an app produced a ridiculous amount of output, the options were to either buffer _all_ of it, which would be a ton of memory usage, or _not_ buffer it, and eventually the perf gain would go away. I'm not totally sure where that ended up landing.
claunia commented 2026-01-31 02:56:19 +00:00
Author
Owner
Copy Link

@NeKJ commented on GitHub (Dec 10, 2020):

Yes, that's true. They did an exceptional job. However, I would really like to squash this last bit, which holds it back. Other terminals, if I remember correctly, when they heuristically sense, that a ton of output is being dumped, they just skip rendering them altogether (and only render the last of them). I think that Konsole does something similar, which is stupendously fast.

@NeKJ commented on GitHub (Dec 10, 2020): Yes, that's true. They did an exceptional job. However, I would really like to squash this last bit, which holds it back. Other terminals, if I remember correctly, when they heuristically sense, that a ton of output is being dumped, they just skip rendering them altogether (and only render the last of them). I think that Konsole does something similar, which is _stupendously_ fast.
claunia commented 2026-01-31 02:56:19 +00:00
Author
Owner
Copy Link

@zadjii-msft commented on GitHub (Dec 10, 2020):

Oh, I don't think they ever got around to shipping the big improvement they were working on. @miniksa optimized a bunch of other parts of the code, that resulted in smaller improvements, something like 5-10% at a time. The thing I think they were working on we ridiculous, like 100% faster.

@zadjii-msft commented on GitHub (Dec 10, 2020): Oh, I don't think they ever got around to shipping the _big_ improvement they were working on. @miniksa optimized a bunch of other parts of the code, that resulted in smaller improvements, something like 5-10% at a time. The thing I _think_ they were working on we ridiculous, like 100% faster.
claunia commented 2026-01-31 02:56:19 +00:00
Author
Owner
Copy Link

@NeKJ commented on GitHub (Dec 10, 2020):

That is very interesting indeed. @miniksa and @lhecker, is that true? It seems to be a big thing. I wonder what happened with that work. Have you dropped it for some reason or is it still on your back log?

@NeKJ commented on GitHub (Dec 10, 2020): That is very interesting indeed. @miniksa and @lhecker, is that true? It seems to be a big thing. I wonder what happened with that work. Have you dropped it for some reason or is it still on your back log?
claunia commented 2026-01-31 02:56:19 +00:00
Author
Owner
Copy Link

@miniksa commented on GitHub (Dec 10, 2020):

I was looking at this in #3075 and https://github.com/microsoft/terminal/tree/dev/miniksa/gotta_go_fast_spsc.

But I think I had spent a few months in a performance hole, popped up to check in a few of the improvements before I was too far gone (#6483, #6839, #6840, #6841, #6918, #6420), and left the queue behind to finish figuring out later as it was consuming an infinite amount of memory. Also around that time, I learned about how we could run PGO against our stuff if only we had Helix set up... so I think I got Helix testing set up (borrowed from the WinUI 2 project, #6992) so I could also use their PGO work. I think PGO might solve some of the outstanding perf issues for us, if we wrote guided tests to exercise the scenarios. That's #6963. And then I think I got pulled onto something else.

Well, you know, and the whole pandemic thing.

But other than that... yeah it's on my backlog.

Going to dupe it to /dup #3075 then. Thanks.

@miniksa commented on GitHub (Dec 10, 2020): I was looking at this in #3075 and https://github.com/microsoft/terminal/tree/dev/miniksa/gotta_go_fast_spsc. But I think I had spent a few months in a performance hole, popped up to check in a few of the improvements before I was too far gone (#6483, #6839, #6840, #6841, #6918, #6420), and left the queue behind to finish figuring out later as it was consuming an infinite amount of memory. Also around that time, I learned about how we could run PGO against our stuff if only we had Helix set up... so I think I got Helix testing set up (borrowed from the WinUI 2 project, #6992) so I could also use their PGO work. I think PGO might solve some of the outstanding perf issues for us, if we wrote guided tests to exercise the scenarios. That's #6963. And then I think I got pulled onto something else. Well, you know, and the whole pandemic thing. But other than that... yeah it's on my backlog. Going to dupe it to /dup #3075 then. Thanks.
claunia commented 2026-01-31 02:56:20 +00:00
Author
Owner
Copy Link

@ghost commented on GitHub (Dec 10, 2020):

Hi! We've identified this issue as a duplicate of another one that already exists on this Issue Tracker. This specific instance is being closed in favor of tracking the concern over on the referenced thread. Thanks for your report!

@ghost commented on GitHub (Dec 10, 2020): Hi! We've identified this issue as a duplicate of another one that already exists on this Issue Tracker. This specific instance is being closed in favor of tracking the concern over on the referenced thread. Thanks for your report!
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
⛺ Reserved
A11yCO
A11yMAS
A11ySev1
A11ySev2
A11ySev3
A11yTTValidated
A11yUsable
A11yVoiceAccess
A11yWCAG
Area-Accessibility
Area-AtlasEngine
Area-AzureShell
Area-Build
Area-Build
Area-Chat
Area-CmdPal
Area-CodeHealth
Area-Commandline
Area-CookedRead
Area-DefApp
Area-Extensibility
Area-Fonts
Area-GroupPolicy
Area-i18n
Area-Input
Area-Interaction
Area-Interop
Area-Localization
Area-Output
Area-Performance
Area-Portable
Area-Quality
Area-Remoting
Area-Rendering
Area-Schema
Area-Server
Area-Settings
Area-SettingsUI
Area-ShellExtension
Area-ShellExtension
Area-ShellExtension
Area-Suggestions
Area-Suggestions
Area-TerminalConnection
Area-TerminalControl
Area-Theming
Area-UserInterface
Area-VT
Area-Windowing
Area-WPFControl
AutoMerge
Blocking-Ingestion
Culprit-Centennial
Culprit-WinUI
Disability-All
Disability-Blind
Disability-LowVision
Disability-Mobility
External-Blocked-WinUI3
Fixed
Gathering-Data
good first issue
HCL-E+D
HCL-WindowsTerminal
Help Wanted
Impact-Compatibility
Impact-Compliance
Impact-Correctness
Impact-Visual
In-PR
InclusionBacklog
InclusionBacklog-Windows TerminalWin32
InclusionCommitted-202206
Issue-Bug
Issue-Docs
Issue-Feature
Issue-Feature
Issue-Question
Issue-Samples
Issue-Scenario
Issue-Task
Needs-Attention
Needs-Author-Feedback
Needs-Bisect
Needs-Discussion
Needs-Repro
Needs-Tag-Fix
Needs-Tag-Fix
Needs-Triage
No-Recent-Activity
Priority-0
Priority-1
Priority-2
Priority-3
Product-Cmd.exe
Product-Colortool
Product-Colortool
Product-Colortool
Product-Conhost
Product-Conpty
Product-Meta
Product-Powershell
Product-Terminal
Product-WSL
pull-request
Mirrored from GitHub Pull Request
 Resolution-Answered
Resolution-By-Design
Resolution-Duplicate
Resolution-External
Resolution-Fix-Available
Resolution-Fix-Committed
Resolution-No-Repro
Resolution-Won't-Fix
Severity-Blocking
Severity-Crash
Severity-DataLoss
spam
this-will-be-a-breaking-change
Tracking-External
WindowsTerminal_Win32
Work-Item
zAskModeBug
zInbox-Bug
No Label Issue-Feature Resolution-Duplicate
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
claunia
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/terminal#11748
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?