Hacker News Reader

Comment by squigz | Hacker News Reader

What problem is having a "fast" terminal solving? I've been using urxvt for years and have never really found it to be slow. Where might I notice a difference with these "modern" "GPU-accelerated" terminals?

View on HN

The delay in between typing and seeing it rendered, drawing large portions of text (which matters if you spend a lot of time in term based editors) etc ...

It's very subjective: some folks (me included) will notice the difference and feel frustrated if it's not fast enough, while others are scratching their head about how it actually makes a difference.

It could also be said, that it's of logical to expect certain things to be fast; especially when they've been around for so long. We're drawing text on the screen here, it should be fast.

Saying it matters with anything else than feeling/comfort would be overreaching.

The issue is that usually these terminals mean "higher throughput" when they say "faster", not "lower latency". The lowest-latency terminal in every test is Xterm, often by a LOT. Alacritty for a long time was actually quite bad at latency--and notably had a high variance on its latency, which is particularly miserable--but I think it improved recently? From what I remember of these benchmarks, someone using urxvt isn't going to be impressed by the supposed speed of Alacritty, if we are talking latency (and I agree: we should be, and everyone should use Xterm, which is actually an insanely good terminal).

As for throughput, I have lived in the terminal for decades, and as long as the various layers don't have massive buffers I honestly don't care how slow the terminal is: if I am dumping megabytes into my terminal backscroll I probably am going "oh shit" and am frantically hitting Ctrl-C... a slow terminal with a small buffer handles that almost immediately. I get the impression that there are maybe some use cases involving high-rate screen updates for apps that happen to run in consoles but are really GUIs... I don't use many of those and in fact try to avoid them, but I could maybe see an advantage for a high-throughput terminal to improve their simulated frame rate?

People writing fast terminal emulator care about throughput, latency and resource utilization. Kitty for instance deliberately limit throughput to keep both latency and CPU/GPU usage reasonable.

Also, by what metric is xterm so fast? I accept the idea that it is fast, even the fastest, but "a lot" seems suspicious to me. From the keyboard to the monitor, there is a lot of hardware and driver latency, I guess tens of milliseconds, so the effect of the terminal, should be relatively minor. I suspect xterm is so fast because the tool used to test it relies on the X server, and because xterm communicates with X directly, the latency will be really low from the point of view of X, but how is it end-to-end? Do we get the same results, with, say, Wayland?

here is some latency tests using an external camera, though that's Windows only, there might've been a similar one for Linux, but not sure

https://chadaustin.me/2024/02/windows-terminal-latency/

The other one where xterm is uber low is https://lwn.net/Articles/751763/ is using this tool with software-based screen capture https://pavelfatin.com/typometer/, not sure how reliable that is as a proxy for end-to-end (at the time of the benchmark Wayland wasn't supported)

I only really notice it when accidentally catting a really large file. Although I prefer kitty, any of these modern terminal emulators just rip through megabytes of text in less than a second, while in older ones you have to wait for half a minute or just sigkill them.

Each time I see a new "fast" terminal emulator I bench it with my only way to do it (`time cat large-text-file`) and urxvt is really quicker than other.

Your buffer is too big: your terminal shouldn't be sitting there for half a minute, as it should be processing Ctrl-C immediately and unrelatedly to its screen updates and sending it, and the remote process should be blocked on a write to its output (which in turn should prevent it from creating more garbage due to the back pressure) because all the buffers between it and you are full. Having ginormous buffers and then wanting the local terminal to be super fast to clear them quickly is kind of pointless as the use case for streaming megabytes of garbage to the terminal and NOT cancelling the operation are effectively 0.

I agree that I've never had a problem with terminal speeds on Linux. If you're using urxvt, that's probably going to do just fine.

Where I have had problems has been on the Mac, where the system default "Terminal.app" or popular alternatives like "iTerm2.app" can each be catastrophically slow if you have a lot of control codes (as in, for example, rapidly paging through a large document in vim with an intensive color scheme active), and it could just take noticeable fractions of a second to redraw a fullscreen terminal window.

Moving to a faster terminal emulator like alacritty or kitty did make a good quality of life improvement for me in that specific use case.

I use Cygwin's mintty on Windows, and the result of `ls` is not instantaneously there. If the windows is resized to big and there are lots of files, I can see each filename get printed out one by one. In Alacritty it shows the entire result immediately.

Also, you may have commands or scripts which print out a lot, like which file in a huge list is currently getting processed, where the entire execution time of the command depends mostly on how fast the terminal is able to print those messages.

Compilation of a large project on a multiple cores can be slowed down by a terminal. Especially if the main language of the project is a fast compiling C. I'm not sure that urxvt can be a bottleneck, and if it can you'll not be able to notice the difference with alacritty without measurements, but with others it can be noticeable without any special equipment.

alo of gpu accelearted terminals are actuallly very slow. because they add silly features. basic text i/o is almost always slower. even on a good gpu! :/

It's mostly about the perceived responsiveness which I think also shouldn't be understated.

Anything that dumps text on the console really fast.

An example I run into fairly often is untarring a backup in verbose mode. With modern NVMes, printing out the filenames to a slow console can be a bottleneck.

"fast" probably depends where you're coming from. Moving to Alacritty (and then WezTerm) from iterm2 was definitely a very noticeable difference for me, and just "felt" better. Of course iterm2 isn't exactly slow, but that feeling of UI immediacy in faster terminals does help me focus on the task at hand. If your existing terminal is fast enough to not notice, I suspect you've already hit the point of diminishing returns.

You can feel it. Specially as 5e92cb50239222b says in throughput. Urxvt is not one of the slow emulators so you will notice it less specially at lower resolutions.

I have used Alacritty for a few years.

Right now I have about 20 open (in sway) and half of them are non-local SSH sessions... so pretty pointless. I only notice SSH latency when the VPN wobbles. Or throughput if I mis-cat a log file instead of using tail...

I complain like crazy if there is any latency in gaming so it seems I'm not latency sensitive in terminals :-) or more likely: reality tempers expectations.

With stacktraces the size of a bible program execution actually slows down if my terminal isn't outputting it fast enough

I use Kitty, which is extremely fast, and I often avoid calling `tail` to print the end of a long log file: the terminal is so fast in displaying it that it's useless.

Another case is when you mistakenly invoke a command that produces a lot of output. With Kitty, terminal output is so fast that the output ended before I could reach Ctrl+C.

I can't remember what the issue was exactly, but Kitty does something that makes it work not-so-nice when SSHing into some machines.

You can ask these questions about pretty much every single performance improvement project. At the end there is always a win:

- cost (this is more relevant to large scale infra perf opt)

- UX (this is what a fast terminal might be achieving)

- energy efficiency (because energy is super cheap these are often overlooked, however battery life might be still relevant)

> energy efficiency

I care about energy efficiency deeply. But in a terminal? You can't be serious.

Each terminal is in the end tied to a single person so there is no runaway scaling of instances possible. Your win in energy consumption is in the single digit watt-hours per person.

One could probably compare the energy savings coming from the terminal rendering to the extra energy consumed by the developer trying to improve performance and it might turn out to be a wash.

As for the perception of speed by people using the terminal. I too am very puzzled how this is different from audiophile movement where people claim to perceive minuscule differences in THD whatever metric they focus on today.

It might be that I've been working over dial-up sessions and intercontinental ssh sessions and the perception of slow starts to creep in when RTT gets to 100ms range. Which is probably orders of magnitude worse and more limiting than the difference between kitty and alacritty.

> But in a terminal? You can't be serious.

After reading Mitchell's writings about terminal development I am not sure.

> Each terminal is in the end tied to a single person

A popular terminal runs on millions of devices. This adds up quickly.

https://mitchellh.com/writing

> energy efficiency

I highly doubt that offloading the rendering to a GPU is more energy efficient. I'm quite sure it's the exact opposite: GPUs are power hungry energy-eaters; commonly.

Sure?

https://blogs.nvidia.com/blog/gpu-energy-efficiency-nersc/

GPUs (namely discrete ones) often have high maximum power draw, but that's because they're generally used for tasks that require computational heavy lifting. That doesn't mean they're particularly power-hungry in terms of watts vs. amount of work done. If you offload e.g. video decoding to a GPU, that's usually more energy-efficient than decoding on the CPU.

(The heavy lifting is probably more energy-efficient on the GPU, too, but that's not directly relevant here.)

urxvt and xterm are also fast terminals. The noticably slow ones are gnome-terminal, konsole, etc. They have pretty bad latency in the time between pressing a key and that letter appearing on screen.

Neither Konsole nor GNOME Terminal are as lean and fast as (U)XTerm, however on day to day use, I fail to see input latency on these. I generally use 60-80WPM depending on what I write and how concentrated I am, and there's no noticeable lag from my perspective.

GNOME terminal was visibly slow in the days of yore, but given that the libraries powering these are already accelerated, I don't think the difference between these "accelerated" terminals are as big as touted w.r.t. GNOME Terminal or KDE's Konsole.

To be fair I haven't tried gnome terminal in some years so maybe it's improved. I have used konsole (well, yakuake, but same thing) more recently and was minorly annoyed by the latency, particularly when scrolling in emacs/etc. I have since swapped out yakuake with kitty with tdrop for the "quake mode" effect.

Yes, Yakuake uses the same Konsole framework, but they might lag behind in terms of framework version IIUC. Konsole supports more features than Yakuake and feels a bit smoother to me since I drive both daily.

Love to collaborate and make some tests with you, too.

Presumably, the same "problem" that gold-plated HDMI connectors are solving.

If you accidentally pipe hundreds of thousands of lines of text (e.g. from find) to stdout, you will feel the difference. Some terminals (e.g. xterm) are particularly slow and will stall until it is done processing all the output. urxvt is not the worst, but could be better, yet doesn't always achieve 60 Hz.

My gripe with (u)rxvt (last I checked) is the atrocious font rendering and character spacing if you chose a full unicode/nerd font.

Yeah, I see no difference either, I used to use urxvt for years, then switched to kitty (which is also hardware accelerated like Alacritty), but not for the supposed "performance" gains but because it's got better features but I can't really tell the difference.

Reply on news.ycombinator.com