Notably this article was written based on Windows Terminal 1.18. That was before WT 1.22, which included this PR: [^1] which roughly doubled the terminal's throughput. That combined with a couple of other PRs in 1.22 made some scenarios up to _16x_ faster[^2]
I daily drive a couple Macs and enjoy them but I can't help but notice they seem slower in the terminal than the alternatives. Can't get any kind of discussion on /r/mac as it's just 'Apple silicon is fast!'
You can run the tests yourself, he describes them in the blog. Used the Is It Snappy! app to measure frames.
I tried the throughput test myself just now between the native macOS terminal and ghostty.
Ghostty:
cat /tmp/lines.txt 0.00s user 0.02s system 36% cpu 0.069 total
Native mac terminal:
cat /tmp/lines.txt 0.00s user 0.02s system 18% cpu 0.115 total
Seems much faster than any of the OP's windows terminals tested except for MinTTY.
Likewise in one unscientific test with Is It Snappy, ghostty took 8 frames to render the output from pressing the key, but I didn't repeat multiple times.
So, seems faster, but I know what you are talking about, I experience it too. Something about using the terminal on macOS feels sluggish compared to alternatives. It's especially noticeable for me over SSH
This has been posted on HN a few times and seems to show that terminal.app is your best bet for most cases if you care about latency: https://danluu.com/term-latency/
Terminal app has no truecolor support, no highres mouse support, no kitty graphics protocol, no double height character support, i'm sure there is more but I now discard it from my tests.
Any chance of getting native support for Serial (DB9/RS232) communication in Windows Terminal? Would love to use it but I'm still using PuTTY and HyperTerminal.
Is there not a suitable CLI or TUI client for Windows that can simply be called from within Windows Terminal? Honest question. I just know that on Linux, it'd be really weird to ask for my terminal emulator to embed a serial client rather than call e.g. screen or minicom from my shell.
I think it has been discussed but not implemented yet. In the meantime, tools like https://github.com/fasteddy516/SimplySerial give what you are looking for instead of those alternative GUI tools.
The PuTTY terminal has a few more features in certain areas but a lot fewer features overall. Also, of course, PuTTY does not share profiles/settings/window tabs+panes with WT, which is a bit of a pain.
Does it still pause scrolling and stop whatever's running if you click on the window or press a key? That's one big reason why I still live in a plain old DOS box. It didn't appear that the Windows terminal developers had ever heard of ctrl-s.
Dang, I've never heard of anyone who actually _wanted_ that behavior haha, I've had so much wasted time in school projects where I thought something was running but it wasn't because I had selected text in cmd.exe haha.
If you are waiting for the output as an indication that a task completed and you never see that output you may think the task is still running but it is actually done.
I am not sure that if it actually stops the program, but it does at least stop programs from printing, so for anything that gives feedback on stderr/stdout you are at least pausing the main thread. I have a mostly-non-threaded program that this happens to, and it does not continue to send messages to other systems until I un-pause it.
Ctrl-Z suspends the program in most UNIX shells. ("fg" to resume)
Ctrl-S may or may not end up stopping the program, depending on how much it's printing, and how much output buffering there is before it blocks on writing more.
All my shell RCs turn off xon/xoff -- that's a relic from the PDP-11 days we can all do without.
Windows has the Scroll Lock button that's supposed to do this if you need it, but typically, just selecting a character in a terminal emulator will stop the scroll while still buffering the output.
Is there a simple way to get the "Legacy Console" back without having to format and reinstall windows?
Installing packages / the windows modules installer is broken.
Not really on 'latency' per se as discussed in the articole but an interesting take on slow terminals is Casey Muratori's famous rant on the topic [0] that led him to write his own terminal [1], a reference renderer for monospace terminal displays that is several orders of magnitude faster than Windows Terminal despite being largely unoptimized.
Another aspect of this is which pipeline is in use for the GPU accelerated terminals. *WezTerm on Windows for example, specific rendering issues occur with default NVIDIA settings related to DXGI.
You will never interact with this pipeline if using the Web GPU vulkan renderer, which has its own issues. I personally experience some form of memory leak / latency when working in terminals that have been open for a 'good' amount of time.
[^1]: https://github.com/microsoft/terminal/pull/17510
[^2]: https://devblogs.microsoft.com/commandline/windows-terminal-...
I forked a colorscripts project and added some true ANSI art after conversion and the built in glyphs look so much better than any other font.
It's great but is there any special rendering for the built in glyphs that's not possible with fonts? Just curious
I daily drive a couple Macs and enjoy them but I can't help but notice they seem slower in the terminal than the alternatives. Can't get any kind of discussion on /r/mac as it's just 'Apple silicon is fast!'
I tried the throughput test myself just now between the native macOS terminal and ghostty.
Ghostty: cat /tmp/lines.txt 0.00s user 0.02s system 36% cpu 0.069 total
Native mac terminal: cat /tmp/lines.txt 0.00s user 0.02s system 18% cpu 0.115 total
Seems much faster than any of the OP's windows terminals tested except for MinTTY.
Likewise in one unscientific test with Is It Snappy, ghostty took 8 frames to render the output from pressing the key, but I didn't repeat multiple times.
So, seems faster, but I know what you are talking about, I experience it too. Something about using the terminal on macOS feels sluggish compared to alternatives. It's especially noticeable for me over SSH
Has happened to me quite a few times.
Ctrl-S may or may not end up stopping the program, depending on how much it's printing, and how much output buffering there is before it blocks on writing more.
Otherwise click the top left icon, go to settings, uncheck QuickEdit.
[0] https://www.youtube.com/watch?v=hxM8QmyZXtg
[1] https://github.com/cmuratori/refterm
You will never interact with this pipeline if using the Web GPU vulkan renderer, which has its own issues. I personally experience some form of memory leak / latency when working in terminals that have been open for a 'good' amount of time.