Terminal Latency on Windows (2024) | Hacker News Reader

Terminal Latency on Windows (2024)

chadaustin.me

113 pointsbariumbitmap93 comments

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]

[^1]: https://github.com/microsoft/terminal/pull/17510

[^2]: https://devblogs.microsoft.com/commandline/windows-terminal-...

Thanks for the work on WT, it was really a massive step up I did not expect after all of these years.

You're most welcome! Working on it to help serve the whole developer ecosystem has been the delight of my career :)

Just want to say built in glyphs makes terminal ANSI art awesome.

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

Any similar benchmarks for MacOS?

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!'

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/

seems like outdated info

This was a great article when it came out, but it’s very outdated. The laptop used is over 10 years old now.

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.

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

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.

I recommend Tera term. https://github.com/TeraTermProject/teraterm/releases

As much as I like PuTTY the ergonomics for "monitor this port as I plug/unplug the USB-to-Serial adapter" are so much better in TeraTerm.

Is there something lacking in PuTTY ?

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.

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.

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.

Indeed. Plus some serial file transfer protocols. At least xmodem, ymodem and kermit.

In case you want to compare the latency on Linux: https://beuke.org/terminal-latency/

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.

That's called QuickEdit Mode and you have been able to turn that off for decades (and installing the new terminal fixes that too.)

Otherwise click the top left icon, go to settings, uncheck QuickEdit.

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.

It stops running? I thought it just stops the output.

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.

Has happened to me quite a few times.

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.

(2024)

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.

[0] https://www.youtube.com/watch?v=hxM8QmyZXtg

[1] https://github.com/cmuratori/refterm

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.

Reply on news.ycombinator.com