3 ms·
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 kon
by oever 8y ago
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
- hd4 8y agoI'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.
- oever 8y agoYes, 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.
- vanderZwan 8y agoHow about Terminology? https://www.enlightenment.org/about-terminology https://www.enlightenment.org/about-terminology
- oever 8y agoTerminology 1.1 takes 26 seconds and 100% CPU on find and 15 seconds and 90% CPU on the bash counting.
- nosjwshere 8y agoan sdl based term would do that https://github.com/Zoomulator/Terminate https://github.com/Zoomulator/Terminate
- fmoralesc 8y ago`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.
- zaat 8y agoI 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.
- jstimpfle 8y agoWhen 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.
- laumars 8y agoI 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).
- jstimpfle 8y agoIt 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.
- zaat 8y agoIt 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.
- sime2009 8y agoCan 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.
- lake99 8y agoAll 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.
- Avamander 8y agoPlease suggest better methods then.
- MaxBarraclough 8y agoAssuming 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?
- blattimwind 8y agoGrab framebuffer at refresh rate and measure the time until your end-of-test marker appears in the FB.
- MaxBarraclough 8y agoThat'd do it.
- snarfy 8y agoI 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.
- def_true_false 8y agoSignificant 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.
- deleted 8y ago[deleted]