4 ms·

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 eno

by hd4 8y ago

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.

oever 8y ago
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.
- vanderZwan 8y ago
  How about Terminology? https://www.enlightenment.org/about-terminology https://www.enlightenment.org/about-terminology
  - oever 8y ago
    Terminology 1.1 takes 26 seconds and 100% CPU on find and 15 seconds and 90% CPU on the bash counting.
- nosjwshere 8y ago
  an 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 ago
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.
- jstimpfle 8y ago
  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.
  - laumars 8y ago
    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).
    - jstimpfle 8y ago
      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.
      - zaat 8y ago
        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.

by hd4 8y ago

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.

oever 8y ago

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.

vanderZwan 8y ago
How about Terminology? https://www.enlightenment.org/about-terminology https://www.enlightenment.org/about-terminology
- oever 8y ago
  Terminology 1.1 takes 26 seconds and 100% CPU on find and 15 seconds and 90% CPU on the bash counting.
nosjwshere 8y ago
an 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 ago

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.

jstimpfle 8y ago
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.
- laumars 8y ago
  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).
  - jstimpfle 8y ago
    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.
    - zaat 8y ago
      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.