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

Terminal output not speed enough #1420

New Issue
Closed
opened 2026-01-30 22:26:37 +00:00 by claunia · 22 comments
claunia commented 2026-01-30 22:26:37 +00:00
Owner
Copy Link

Originally created by @MathiasMagnus on GitHub (May 30, 2019).

Originally assigned to: @miniksa on GitHub.

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
Originally created by @MathiasMagnus on GitHub (May 30, 2019). Originally assigned to: @miniksa on GitHub. 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 ```none 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 ```powershell 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](https://github.com/microsoft/terminal/issues/521) 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 ```
claunia commented 2026-01-30 22:26:38 +00:00
Author
Owner
Copy Link

@MathiasMagnus commented on GitHub (May 30, 2019):

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.

@MathiasMagnus commented on GitHub (May 30, 2019): 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.
claunia commented 2026-01-30 22:26:38 +00:00
Author
Owner
Copy Link

@zadjii-msft commented on GitHub (May 30, 2019):

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.

@zadjii-msft commented on GitHub (May 30, 2019): 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.
claunia commented 2026-01-30 22:26:38 +00:00
Author
Owner
Copy Link

@oising commented on GitHub (May 30, 2019):

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

@oising commented on GitHub (May 30, 2019): 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
claunia commented 2026-01-30 22:26:39 +00:00
Author
Owner
Copy Link

@miniksa commented on GitHub (May 30, 2019):

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.

@miniksa commented on GitHub (May 30, 2019): 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.
claunia commented 2026-01-30 22:26:39 +00:00
Author
Owner
Copy Link

@MathiasMagnus commented on GitHub (May 31, 2019):

@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?) ;)

@MathiasMagnus commented on GitHub (May 31, 2019): @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?) ;)
claunia commented 2026-01-30 22:26:39 +00:00
Author
Owner
Copy Link

@pingzing commented on GitHub (Jun 10, 2019):

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
@pingzing commented on GitHub (Jun 10, 2019): To throw another torture-test onto the pile, old Conhost noticeably outperforms the new terminal when running a tight loop: ```powershell 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
claunia commented 2026-01-30 22:26:39 +00:00
Author
Owner
Copy Link

@Po-wei commented on GitHub (Oct 11, 2019):

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!

@Po-wei commented on GitHub (Oct 11, 2019): 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" ```c++ #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!
claunia commented 2026-01-30 22:26:39 +00:00
Author
Owner
Copy Link

@rlpeacock commented on GitHub (Oct 25, 2019):

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!

@rlpeacock commented on GitHub (Oct 25, 2019): 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!
claunia commented 2026-01-30 22:26:40 +00:00
Author
Owner
Copy Link

@nikbackm commented on GitHub (Nov 26, 2019):

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.

@nikbackm commented on GitHub (Nov 26, 2019): 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.
claunia commented 2026-01-30 22:26:40 +00:00
Author
Owner
Copy Link

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

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

CMD.EXE under Windows Terminal (Preview) Version: 0.9.433.0: 6.70 sec
windows-terminal-cmd

Cygwin under Windows Terminal (Preview) Version: 0.9.433.0: 14.594 sec
windows-terminal-cygwin

Powershell Core 6.2.0 under Windows Terminal (Preview) Version: 0.9.433.0: 18.458 sec
windows-terminal-powershell

Git-Bash under MinTTY3.1.0: 1.058 sec
mintty3 1 0-git-bash

Putty 0.71 connected to an Ubuntu OS: 2.763 sec
putty-ubuntu

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

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

xterm under XWing on Windows 10 v1909: 3.311sec
xterm-cygwin-xwing

Arch Linux xterm:3.822 sec
archlinux-xterm

Arch Linux Konsole: 0.616 sec
archlinux-konsole

@NeKJ commented on GitHub (Mar 10, 2020): 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](https://user-images.githubusercontent.com/5416165/76306518-b1dca080-62cf-11ea-917c-4b0ada25ee51.png) CMD.EXE under Windows Terminal (Preview) Version: 0.9.433.0: **6.70 sec** ![windows-terminal-cmd](https://user-images.githubusercontent.com/5416165/76306511-b012dd00-62cf-11ea-897a-c6a96f69cadb.png) Cygwin under Windows Terminal (Preview) Version: 0.9.433.0: **14.594 sec** ![windows-terminal-cygwin](https://user-images.githubusercontent.com/5416165/76306512-b0ab7380-62cf-11ea-992f-847af3556cd5.png) Powershell Core 6.2.0 under Windows Terminal (Preview) Version: 0.9.433.0: **18.458 sec** ![windows-terminal-powershell](https://user-images.githubusercontent.com/5416165/76306513-b0ab7380-62cf-11ea-872b-0eed9d7c422a.png) Git-Bash under MinTTY3.1.0: **1.058 sec** ![mintty3 1 0-git-bash](https://user-images.githubusercontent.com/5416165/76306503-ae491980-62cf-11ea-91ab-ec3aae6ef1fc.png) Putty 0.71 connected to an Ubuntu OS: **2.763 sec** ![putty-ubuntu](https://user-images.githubusercontent.com/5416165/76306505-af7a4680-62cf-11ea-8cef-f316b4fdc64c.PNG) konsole with cygwin under XWing on Windows 10 v1909:**3.198 sec** ![konsole-cygwin-xwing](https://user-images.githubusercontent.com/5416165/76306519-b1dca080-62cf-11ea-9ee0-dfb5622be067.png) urxvt with cygwin under XWing on Windows 10 v1909: **3.144 sec** ![rxvt-cygwin-xwing](https://user-images.githubusercontent.com/5416165/76306509-b012dd00-62cf-11ea-87b8-f701c6377ecd.png) xterm under XWing on Windows 10 v1909: **3.311sec** ![xterm-cygwin-xwing](https://user-images.githubusercontent.com/5416165/76306514-b1440a00-62cf-11ea-9f49-ee7bf55865f6.png) Arch Linux xterm:**3.822 sec** ![archlinux-xterm](https://user-images.githubusercontent.com/5416165/76306516-b1440a00-62cf-11ea-905d-974581e0dc9e.png) Arch Linux Konsole: **0.616 sec** ![archlinux-konsole](https://user-images.githubusercontent.com/5416165/76306515-b1440a00-62cf-11ea-958b-72be1e4d742d.png)
claunia commented 2026-01-30 22:26:40 +00:00
Author
Owner
Copy Link

@miniksa commented on GitHub (Apr 8, 2020):

set "startTime=%time%" && type big.txt && call echo started: %^startTime% finished: %^time%
@miniksa commented on GitHub (Apr 8, 2020): ``` set "startTime=%time%" && type big.txt && call echo started: %^startTime% finished: %^time% ```
claunia commented 2026-01-30 22:26:40 +00:00
Author
Owner
Copy Link

@miniksa commented on GitHub (Apr 8, 2020):

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 commented on GitHub (Apr 8, 2020): 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.
claunia commented 2026-01-30 22:26:40 +00:00
Author
Owner
Copy Link

@miniksa commented on GitHub (Apr 22, 2020):

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
@miniksa commented on GitHub (Apr 22, 2020): 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 ``` <details><summary>Raw Data</summary> |Ver|CMD|PowerShell inbox|PS Core 7|Ubuntu Bash| |---|---|---|---|---| |1909 RTM Conhost.exe |started: 13:34:01.81 finished: 13:34:18.59<br />started: 13:35:06.05 finished: 13:35:19.42<br />started: 13:35:31.69 finished: 13:35:44.92|TotalSeconds : 39.0748941<br />TotalSeconds : 38.1844985<br />TotalSeconds : 37.8779369|TotalSeconds : 28.9303056<br />TotalSeconds : 25.8062131<br />TotalSeconds : 25.5502147|real 0m17.770s user 0m0.000s sys 0m1.578s<br />real 0m14.201s user 0m0.000s sys 0m1.484s<br />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<br />started: 13:49:41.88 finished: 13:49:54.16<br />started: 13:50:00.83 finished: 13:50:12.91|TotalSeconds : 41.1824883<br />TotalSeconds : 37.038748<br />TotalSeconds : 36.2204327|TotalSeconds : 29.3881203<br />TotalSeconds : 25.6277464<br />TotalSeconds : 24.8114259|real 0m16.630s user 0m0.000s sys 0m1.906s<br />real 0m13.423s user 0m0.000s sys 0m1.516s<br />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<br />started: 14:05:01.29 finished: 14:05:18.06<br />started: 14:05:26.57 finished: 14:05:41.11 | TotalSeconds : 30.6881614<br />TotalSeconds : 28.3423776<br />TotalSeconds : 28.0171003 | TotalSeconds : 24.7604087<br />TotalSeconds : 21.6304502<br />TotalSeconds : 21.5883383 | real 0m17.024s user 0m0.000s sys 0m1.375s<br />real 0m15.480s user 0m0.000s sys 0m1.250s<br />real 0m15.491s user 0m0.000s sys 0m1.188s | |#5345 OpenConsole.exe |started: 14:14:32.23 finished: 14:14:48.19<br />started: 14:14:59.38 finished: 14:15:11.73<br />started: 14:15:18.37 finished: 14:15:30.45 | TotalSeconds : 39.7205291<br />TotalSeconds : 35.5094491<br />TotalSeconds : 36.1618336 | TotalSeconds : 27.7631558<br />TotalSeconds : 25.1014372<br />TotalSeconds : 23.7343088 | real 0m18.081s user 0m0.000s sys 0m1.406s<br />real 0m13.328s user 0m0.000s sys 0m1.313s<br />real 0m13.520s user 0m0.000s sys 0m1.250s| |#5345 WindowsTerminal.exe | started: 14:24:00.98 finished: 14:24:10.26<br />started: 14:24:17.24 finished: 14:24:26.36<br />started: 14:24:31.64 finished: 14:24:40.77 | TotalSeconds : 21.8950718<br />TotalSeconds : 21.3628002<br />TotalSeconds : 21.7771862 | TotalSeconds : 15.9198153<br />TotalSeconds : 16.0093769<br />TotalSeconds : 15.9133785 | real 0m9.723s user 0m0.000s sys 0m0.859s<br />real 0m9.783s user 0m0.000s sys 0m1.172s<br />real 0m9.855s user 0m0.000s sys 0m0.969s| </details> |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|
claunia commented 2026-01-30 22:26:41 +00:00
Author
Owner
Copy Link

@NeKJ commented on GitHub (Apr 22, 2020):

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

@NeKJ commented on GitHub (Apr 22, 2020): @miniksa Keep up the good work! :) if you need any help or testing just let us know.
claunia commented 2026-01-30 22:26:41 +00:00
Author
Owner
Copy Link

@miniksa commented on GitHub (Apr 22, 2020):

@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 commented on GitHub (Apr 22, 2020): @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.
claunia commented 2026-01-30 22:26:41 +00:00
Author
Owner
Copy Link

@miniksa commented on GitHub (Apr 22, 2020):

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

@miniksa commented on GitHub (Apr 22, 2020): #3075 looks like a good place to focus on other massive-output work Post 1.0.
claunia commented 2026-01-30 22:26:41 +00:00
Author
Owner
Copy Link

@ghost commented on GitHub (May 5, 2020):

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

Handy links:

@ghost commented on GitHub (May 5, 2020): :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](https://github.com/microsoft/terminal/releases/tag/v0.11.1251.0 (1.0rc1)) * [Store Download](https://www.microsoft.com/store/apps/9n0dx20hk701?cid=storebadge&ocid=badge)
claunia commented 2026-01-30 22:26:42 +00:00
Author
Owner
Copy Link

@intractabilis commented on GitHub (May 27, 2020):

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 commented on GitHub (May 27, 2020): 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.
claunia commented 2026-01-30 22:26:42 +00:00
Author
Owner
Copy Link

@intractabilis commented on GitHub (May 28, 2020):

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

Fluent Terminal 0.7.1.0: 2930s

@intractabilis commented on GitHub (May 28, 2020): I tested Fluent Terminal as well, at least Windows Terminal is faster than that. Fluent Terminal 0.7.1.0: 2930s
claunia commented 2026-01-30 22:26:42 +00:00
Author
Owner
Copy Link

@eolalde commented on GitHub (Jun 1, 2020):

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.

@eolalde commented on GitHub (Jun 1, 2020): 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.
claunia commented 2026-01-30 22:26:42 +00:00
Author
Owner
Copy Link

@skyline75489 commented on GitHub (Jun 11, 2020):

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

@skyline75489 commented on GitHub (Jun 11, 2020): 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
claunia commented 2026-01-30 22:26:43 +00:00
Author
Owner
Copy Link

@cairijun commented on GitHub (Jun 15, 2020):

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.

@cairijun commented on GitHub (Jun 15, 2020): > 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.
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 Area-Performance Issue-Task Needs-Tag-Fix Priority-0 Product-Terminal Resolution-Fix-Committed
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#1420
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?