Terminal: Terminal output not speed enough

[MathiasMagnus]

The claims on launch were that the speed of the terminal is superb. Looking at the code it does seem very much like it, that the fastest technologies are used and the coding standards are extremely high. However, when I tried to measure these claims, I was surprised that comparing it with Fluent Terminal (which is built atop web technologies) outperforms Windows Terminal in raw output speed.

Environment

Windows build number: Microsoft Windows [Version 10.0.18362.116]
Windows Terminal version (if applicable): commit id d24d647c
Fluent Terminal: 0.4.1.0

Steps to reproduce

In my favorite Ubuntu WSL instance, I issued

Get-ChildItem /bin/,/boot/,/etc/,/home/,/lib,/lib64/,/opt/,/sbin/,/tmp/,/usr/,/var/ -Recurse -ReadOnly -ErrorAction SilentlyContinue | Out-String | New-Variable -Name Result;
Measure-Command { Write-Host $Result }

Expected behavior

I'd have guessed Windows Terminal to be the fastest when compared with Fluent Terminal (my current terminal of choice) and the old-school terminal. Was there a goal for performance? This is totally a non critical issue, I just wanted to let you guys know. (Critical issue is AltGr combinations not working. Until that's not sorted out, I literally cannot type in the terminal.)

Actual behavior

Old-school terminal

Days              : 0
Hours             : 0
Minutes           : 0
Seconds           : 9
Milliseconds      : 107
Ticks             : 91073049
TotalDays         : 0.000105408621527778
TotalHours        : 0.00252980691666667
TotalMinutes      : 0.151788415
TotalSeconds      : 9.1073049
TotalMilliseconds : 9107.3049

Fluent Terminal

Days              : 0
Hours             : 0
Minutes           : 0
Seconds           : 4
Milliseconds      : 243
Ticks             : 42433973
TotalDays         : 4.91133946759259E-05
TotalHours        : 0.00117872147222222
TotalMinutes      : 0.0707232883333333
TotalSeconds      : 4.2433973
TotalMilliseconds : 4243.3973

Windows Terminal

Days              : 0
Hours             : 0
Minutes           : 0
Seconds           : 6
Milliseconds      : 130
Ticks             : 61304207
TotalDays         : 7.0953943287037E-05
TotalHours        : 0.00170289463888889
TotalMinutes      : 0.102173678333333
TotalSeconds      : 6.1304207
TotalMilliseconds : 6130.4207

[MathiasMagnus]

FWIW, terminal output is smoother on Windows Terminal, while Fluent Terminal is noticeably "choppier". If that is the primary source of perf difference, choosing smoothness over raw perf is a totally viable choice. Again, just sharing the info.

[zadjii-msft]

Well, the goal certainly is to be faster. We haven't necessarily optimized all that much yet - we've been focusing mostly on getting the foundations up. This is definitely a path we should profile, and make sure to get every ounce of perf out of. @miniksa because he's been doing a ton of this recently.

I wouldn't be surprised if part of this is due to conpty getting in the way. I don't know if Fluent Terminal uses winpty as it's pty API, or if it's just using a pair of pipes directly to wsl. If it's using direct pipes, then it's definitely going to have a speed edge till we can implement a passthrough mode for conpty.

[oising]

I think a decent part of this is due to windows terminal performing a full repaint of the visible buffer for every change. It doesn't do differential rendering yet (only painting the parts/regions of the screen that changed)

edit: there's an issue tracking this here - https://github.com/microsoft/terminal/issues/778

[miniksa]

Yes, I very much want to improve this.

I am personally very passionate about the performance of this and want to strive to beat competitors in this area. I am glad you filed this issue so I can use it as a test case when I get time to focus on the raw performance and make this improve. But please be patient.

[MathiasMagnus]

@miniksa I am patient, no need to rush :) As I said, there are more important issues before this, although I too am very passionate about performance. (I'm a GPGPU programmer, what else would I be professionally passionate about?) ;)

[pingzing]

To throw another torture-test onto the pile, old Conhost noticeably outperforms the new terminal when running a tight loop:

for($r = 0; $r -le 255; $r++) {
    for($g = 0; $g -le 255; $g++) {
        for($b = 0; $b -le 255; $b++) {
            Write-Host "`e[38;2;$r;$g;$($b)m█`e[0m" -NoNewline
        }
    }
}

(Was creating a short demo to show off 24-bit color support, noticed choppiness)

Video evidence (gfycat link, because nobody wants to load a 9MB gif: https://gfycat.com/thinlividclumber)

Details:

OS: Windows 10 18362.145
Windows Terminal Version: tag: v0.1.1581.0, built in Release x64
Hardware:

• Lenovo Yoga X1 3rd gen
• RAM: 16GB RAM
• CPU: Intel i7-8550U, 1.8 GHz
• GPU: Intel UHD Graphics 620

[Po-wei]

I accidentally found this. While I was outputing large record to stdout, I found the build-it terminal in VS code is really fast.

this is a simple test code"

#include <iostream>
using namespace std;
int main()
{
    for(int i = 0 ; i < 10000 ; i++) {
        cout << "NUMBER " << i <<std::endl;
        cout << "TEST STRING" <<std::endl;
    }
}

The legacy cmd use ~2.5 sec
The mintty use 0.3 sec (but choppier)

The VS code terminal ~5.8 sec (really smooth)
The windows new Terminal use 3.5sec (really smooth)
The VScode terminal with remote development ~0.2sec (really smooth really fast (what happen?)

That is really interesting!

[rlpeacock]

terminal is noticeably sluggish when dealing with large amounts of output, so I did some comparisons.

Ubuntu WSL2 terminal v. 06.2951.0 on Surface Laptop 2
baseline:

time for i in {1..100000}; do echo $i; done > /dev/null
real    0m0.915s
user    0m0.641s
sys     0m0.266s

now actually draw output

time for i in {1..100000}; do echo $i; done
real    0m56.350s
user    0m5.547s
sys     0m9.953s

for comparison, conemu does worse:

real    1m3.215s
user    0m1.266s
sys     0m1.531s

but the old terminal (conhost?) does much better:

real    0m36.795s
user    0m2.781s
sys     0m4.484s

vscode with remote extension shell into WSL does much much better!

real    0m2.653s
user    0m1.125s
sys     0m1.266s

But gnome-terminal via VcXsrv leads the pack:

real    0m1.799s
user    0m0.859s
sys    0m0.891s

Not really fair to compare it to my Linux deskstop but...

real 0m0.846s # it's .35 when output goes to /dev/null
user 0m0.322s
sys 0m0.258s

Anyway, I guess the point is, we need about an order of magnitude improvement!

[nikbackm]

How about comparisons with conhost.exe?

I timed the time needed to simply type a text file in Windows Terminal (0.6.2951.0) and Windows Console.

The Console is consistently 10 times faster or more.

[NeKJ]

I also have done some measurements using various terminals and environments for comparison reasons. The test used was to dump (cat for bash/get-content for powershell/type for CMD.exe) a big text file that is available here: https://norvig.com/big.txt. I hope these would be helpful and that Windows Terminal will soon get to the same level of performance as the best terminal performers do. Here are the results:

cmd.exe on Windows 10 v1909: 3.66 sec

CMD.EXE under Windows Terminal (Preview) Version: 0.9.433.0: 6.70 sec

Cygwin under Windows Terminal (Preview) Version: 0.9.433.0: 14.594 sec

Powershell Core 6.2.0 under Windows Terminal (Preview) Version: 0.9.433.0: 18.458 sec

Git-Bash under MinTTY3.1.0: 1.058 sec

Putty 0.71 connected to an Ubuntu OS: 2.763 sec

konsole with cygwin under XWing on Windows 10 v1909:3.198 sec

urxvt with cygwin under XWing on Windows 10 v1909: 3.144 sec

xterm under XWing on Windows 10 v1909: 3.311sec

Arch Linux xterm:3.822 sec

Arch Linux Konsole: 0.616 sec

[miniksa]

set "startTime=%time%" && type big.txt && call echo started: %^startTime% finished: %^time%

[miniksa]

w/ big.txt, I'm getting:

CMD + conhost x64 opt build:
19603.1001 (my dev box)
9-11 seconds minimized and unminimized

351dc9c6acd42fea4b4ac96e6ea755486bb2a1b1
9-11 seconds minimized and unminimized

18362.270 (1903 release patched, my home PC)
9-11 seconds minimized and unminimized.

[miniksa]

MINIKSA-STUDIO
Surface Studio 2 i7-7820HQ, GTX 1070, 32GB, 1TB
Windows 10 Enterprise x64 en_US 18363.778 (1909 RTM)
4500x3000 display @ 200% DPI

Conhosts are 120x30 with 14px Lucida Console, GDI renderer.
Terminals are 120x30 with 10pt (14px) Lucida Console, DX renderer.

CMD command

set "startTime=%time%" && type big.txt && call echo started: %^startTime% finished: %^time%

PowerShell command

Measure-Command { Get-Content -ReadCount 0 big.txt | Out-Default }

Ubuntu Bash command

time cat big.txt

Raw Data

|Ver|CMD|PowerShell inbox|PS Core 7|Ubuntu Bash|
|---|---|---|---|---|
|1909 RTM Conhost.exe |started: 13:34:01.81 finished: 13:34:18.59
started: 13:35:06.05 finished: 13:35:19.42
started: 13:35:31.69 finished: 13:35:44.92|TotalSeconds : 39.0748941
TotalSeconds : 38.1844985
TotalSeconds : 37.8779369|TotalSeconds : 28.9303056
TotalSeconds : 25.8062131
TotalSeconds : 25.5502147|real 0m17.770s user 0m0.000s sys 0m1.578s
real 0m14.201s user 0m0.000s sys 0m1.484s
real 0m13.844s user 0m0.000s sys 0m1.656s|
|0.11.1121.0 OpenConsole.exe |started: 13:49:16.86 finished: 13:49:32.32
started: 13:49:41.88 finished: 13:49:54.16
started: 13:50:00.83 finished: 13:50:12.91|TotalSeconds : 41.1824883
TotalSeconds : 37.038748
TotalSeconds : 36.2204327|TotalSeconds : 29.3881203
TotalSeconds : 25.6277464
TotalSeconds : 24.8114259|real 0m16.630s user 0m0.000s sys 0m1.906s
real 0m13.423s user 0m0.000s sys 0m1.516s
real 0m13.421s user 0m0.000s sys 0m1.859s|
|0.11.1121.0 WindowsTerminal.exe | started: 14:04:37.04 finished: 14:04:54.89
started: 14:05:01.29 finished: 14:05:18.06
started: 14:05:26.57 finished: 14:05:41.11 | TotalSeconds : 30.6881614
TotalSeconds : 28.3423776
TotalSeconds : 28.0171003 | TotalSeconds : 24.7604087
TotalSeconds : 21.6304502
TotalSeconds : 21.5883383 | real 0m17.024s user 0m0.000s sys 0m1.375s
real 0m15.480s user 0m0.000s sys 0m1.250s
real 0m15.491s user 0m0.000s sys 0m1.188s |
|#5345 OpenConsole.exe |started: 14:14:32.23 finished: 14:14:48.19
started: 14:14:59.38 finished: 14:15:11.73
started: 14:15:18.37 finished: 14:15:30.45 | TotalSeconds : 39.7205291
TotalSeconds : 35.5094491
TotalSeconds : 36.1618336 | TotalSeconds : 27.7631558
TotalSeconds : 25.1014372
TotalSeconds : 23.7343088 | real 0m18.081s user 0m0.000s sys 0m1.406s
real 0m13.328s user 0m0.000s sys 0m1.313s
real 0m13.520s user 0m0.000s sys 0m1.250s|
|#5345 WindowsTerminal.exe | started: 14:24:00.98 finished: 14:24:10.26
started: 14:24:17.24 finished: 14:24:26.36
started: 14:24:31.64 finished: 14:24:40.77 | TotalSeconds : 21.8950718
TotalSeconds : 21.3628002
TotalSeconds : 21.7771862 | TotalSeconds : 15.9198153
TotalSeconds : 16.0093769
TotalSeconds : 15.9133785 | real 0m9.723s user 0m0.000s sys 0m0.859s
real 0m9.783s user 0m0.000s sys 0m1.172s
real 0m9.855s user 0m0.000s sys 0m0.969s|

|Ver|CMD|PowerShell inbox|PS Core 7|Ubuntu Bash|
|---|---|---|---|---|
|1909 RTM Conhost.exe |14.46s|38.38s|26.76s|15.27s|
|0.11.1121.0 OpenConsole.exe |13.27s|38.41s|26.61s|14.49s|
|0.11.1121.0 WindowsTerminal.exe |16.39s|29.02s|22.66s|16.00s|
|#5345 OpenConsole.exe |13.47s|37.13s|25.53s|14.98s|
|#5345 WindowsTerminal.exe |9.18s|21.68s|15.95s|9.79s|

[NeKJ]

@miniksa Keep up the good work! :) if you need any help or testing just let us know.

[miniksa]

@NeKJ, I believe that the testing results show that Terminal is "speed enough" for 1.0 release with the differential rendering that #5345 is about to bring in under a slightly punishing environment (200% DPI on a massive display, mobile-type processor with the i7 HQ). So I'm going to mark this one as "complete" with #5345 and we can create future follow on post-1.0 items for specific performance issues beyond this point.

[miniksa]

3075 looks like a good place to focus on other massive-output work Post 1.0.

[msftbot[bot]]

:tada:This issue was addressed in #5345, which has now been successfully released as Windows Terminal Release Candidate v0.11.1251.0 (1.0rc1).:tada:

Handy links:

• Release Notes
• Store Download

[intractabilis]

I have a console program that outputs a lot of tracing text. I did some performance tests.

Windows Terminal v1.0.1401.0: 1600s
Vanilla conhost: 700s
Alacritty: 808s
The same code compiled and run on Linux in Tilix terminal (same hardware): 40s.

[intractabilis]

I tested Fluent Terminal as well, at least Windows Terminal is faster than that.

Fluent Terminal 0.7.1.0: 2930s

[eolalde]

The Windows Terminal I'm running is fast (Stable release):
Windows Terminal
Version: 1.0.1401.0

Although, while it's writing STDOUT really fast, there is a long delay to interrupt the foreground process, almost as if the terminal is not able to output the text rapidly and send the interruption sequence to the underlying shell. I would imagine that it makes more sense to prioritize the user's input if there's a bottleneck somewhere.

[skyline75489]

With #6206 merged, I'm getting the time halved on my machine. When 1.1 is released in the future, it'd be a good time for a rematch . @miniksa

[richardtsai]

The Windows Terminal I'm running is fast (Stable release):
Windows Terminal
Version: 1.0.1401.0

Although, while it's writing STDOUT really fast, there is a long delay to interrupt the foreground process, almost as if the terminal is not able to output the text rapidly and send the interruption sequence to the underlying shell. I would imagine that it makes more sense to prioritize the user's input if there's a bottleneck somewhere.

There's #6258 reporting the interruption issue. IMO responsiveness much more important than throughput on this particular issue.