Hacker News new | past | comments | ask | show | jobs | submit login

Here's a YouTuber doing some tests.

https://youtu.be/PZPMvTvUf1Y?t=586

Was a lot faster there.






Displaying gobs of output in a terminal is pretty much the most useless benchmark you can do for a terminal emulator. You never watch output that goes by faster than you can read, unless you're actively watching movies through aalib or libcaca.

I would be happy to have a "framedrop" equivalent for terminals when this happens, as it's totally useless from my perspective.

Not to say that optimizing throughput it's useless (total time adds up over the course of a day), but latency and start-up time are really what matters in a terminal emulator.

It's also hard to measure correctly, because some terminal features such as output reflow and ligature support hide major spikes in latency that you only experience occasionally but can be incredibly annoying (say hi to all url regex matchers!).

alacritty felt absolutely abysmal in the latency department when I last tried it one year ago, which is even worse than most libvte based terminals.

kitty is much better, but it's not exactly a lightweight terminal. It still starts in no less than a full second compared to mere a tenth of a second of urxvt, xterm or mlterm. urxvt always felt more consistent to me, but all three outclass pretty much all other terminals I ever tried.

For those using a tiling window manager, the built-in tabbing and multi-window support is pretty much useless too. Having true-color support is probably the only big argument I can see, which is nice to have for inband images, but again.. something rarely used in practice.


> You never watch output that goes by faster than you can read, unless you're actively watching movies through aalib or libcaca.

This is not true for me.

During development I often run programs that spew an enormous quantity of log output, and I'm watching to see if I notice a pattern in the output visually, or if it just looks normal. Either some critical or warning message in a different colour or boldface, or a shape to the messages that I'd recognise.

Although in principle I could use various output filters, grep etc., sometimes that's effort and I'd rather just run the thing and have it run quickly.

Also it's convenient to have all the output readily available if I do want to look at something that happened, as I can scroll to that place and look at pages of surrounding context in detail. If I use output filters, then I have to faff about re-running the program with different filters, or with all outputs enabled so I can step through everything around the event of interest.

Admittedly sometimes its better to output to a file and search the file, but sometimes visual output at 60Hz works quite well.

I have been known to skim manuals very fast as well. I guess in the era when man pages were everything, I got used to scrolling really fast to look for things of interest. It's interesting that a brain is able to recognise particular word-forms that flick by extremely fast, much faster than reading them. I've had people tell me they cannot do this, so I guess it's a learned skill.


Not only that, but when some terminal program decides to spew a bunch of output again and you don't want to interrupt it, you're going to have to wait until it's finished before you regain control.

No one wants to waste their time waiting for something that could be done already.

So faster terminal output can make a real, useful difference in everyday use.


For this situation, an action to skip output until it settles would be even better. A fast terminal isn't as fast as no terminal.



Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: