Hacker News Reader

Comment by hd4 | Hacker News Reader

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.

View on HN

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.

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

`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.

Reply on news.ycombinator.com