Terminal output speed improvement

[NeKJ]

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

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:

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

[zadjii-msft]

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.

[NeKJ]

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.

[zadjii-msft]

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.

[NeKJ]

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?

[miniksa]

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.

[ghost]

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!