Hacker News Reader

Comment by oever | Hacker News Reader

Two simple speed tests:

    time find ~

/dev/null takes 8 seconds

alacritty takes 8.5 seconds and uses 75% CPU

kitty takes 15 seconds and uses 100% CPU

konsole takes 16 seconds and uses 100% CPU

    time for i in {1..2000000}; do echo $i; done

/dev/null takes 8 seconds

alacritty takes 16 seconds and uses 75% CPU

kitty takes 17 seconds and uses 100% CPU

konsole takes 16 seconds and uses 98% CPU

View on HN

Can we not start throwing around these bullshit `time blah` tests. They don't measure what people thing they measure. It doesn't measure rendering speed at all.

It does vaguely measure two things:

1) How big the buffer is on the terminal when it reads in lots of output. If the buffer is as big as the output then your test reports a figure close to the `/dev/null` test. Not useful.

2) How well the terminal is in SKIPPING the rendering of lots of output. No normal terminal tries to render all of the text on screen.

All that, and it gets worse. "time find ~" always reported something like 2.x seconds for me, no matter which terminal I used (kitty, alacritty, urxvt, st, konsole), but I know from observing the scrolling lines that it always took about 15 seconds in each terminal. It basically means the command has sent the characters to the buffer, and then exited, but the terminal has not finished rendering its buffer.

Please suggest better methods then.

Assuming the terminal programs don't 'announce' when they've finished rendering, the only way to this test properly would be a white-box approach, hooking into the code of the various terminal programs, right?

Grab framebuffer at refresh rate and measure the time until your end-of-test marker appears in the FB.

That'd do it.

A good stopwatch.

I think that https://pavelfatin.com/typometer/ gets close to checking the actual perceived quickness of a terminal. It measures the time from keyboard signal to pixels on the screen.

I would much prefer a terminal that still provided interactivity when text was scrolling in other parts than raw speed. Open up two panes in tmux or your favorite split screen with text scrolling in one and measure latency in the other pane with typometer and I will use whatever comes up to the top.

I think this works:

    START=`date +%S.%N` && find ~ && echo $START && date +%S.%N

I do not care about these numbers at all.

How long between key press and character render? That's all I care about. 24 cores and still have lag when I type. My 7mhz Amiga 500 had a more fluid GUI than modern PCs. It's disgusting.

Significant part of that lag might be coming from the input device you are using. E.g. recently people noticed that one of the latest (?) Macbook keyboards had more latency than an external Apple keyboard.

I'm guessing you're on KDE (as am I) but it would be cool to see GNOME Terminal compared also. What I got from these results is that Konsole is already good enough to not bother switching.

Yes, I'm on KDE on X. gnome-terminal does not work (easily) on my distro so I cannot measure that. I did measure xterm which takes over a minute for both tests and also stresses out X. None of the other terminal emulators did that.

Still, I wonder if the terminal emulators could use less CPU and be faster if they refreshed only with the frequency of the monitor.

An interesting insight from the tests is that the execution speed of a program can depend on the speed of the terminal emulator.

How about Terminology?

https://www.enlightenment.org/about-terminology

Terminology 1.1 takes 26 seconds and 100% CPU on find and 15 seconds and 90% CPU on the bash counting.

`time find ~` took 5.12 seconds and 38% cpu in gnome-terminal here. kitty took 4.32 and 48% cpu, in comparison.

EDIT: alacritty took 4.15 and 54% cpu.

I should note these results are all from second runs.

I switched from Gnome Terminal after running large duplicity backup with -v failed repeatedly, apparently because the terminal didn't held the load. Switching to urxvt256-ml solved the problem.

When the terminal is too slow, the producer is throttled. This is called flow control, which is implemented by putting the consumer to sleep when the buffer from the producer to the consumer terminal is full. No backup program should fail because the terminal is to slow.

I guess that would depend on whether the backup is reading from and/or writing to an external drive without read/write buffers (eg the early CD writers from the 90s). Having the handler program paused might cause io errors there which would legitimately cause the backup to fail.

However I do agree with your point that this "shouldn't" happen in practice (ie any decent hardware you'd expect to have buffers to prevent that kind of write errors).

It is most certainly reading from a drive, or from a TCP stream. Reading from CD-ROMs shouldn't be a problem either. In other words, I doubt that the terminal was the actual problem.

It reads from a drive, encrypts each file and writes it, so there is an element of a large buffer to hold.

I Wouldn't think that the terminal is the actual problem, but running the same job side by side consistently failed on the gnome terminal and finished successfully on urxvt.

On a side note, OP remark on CD-ROMs was regarding writing, CD-ROMs write feed had to be an uninterrupted, continuous stream, and the smallest hiccup would blow the operation and render the media useless.

Yup. It wasnt fun writing CDs back in then days

Reply on news.ycombinator.com