4 ms·

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.

by sime2009 8y ago

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.

lake99 8y ago
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.
Avamander 8y ago
Please suggest better methods then.
- MaxBarraclough 8y ago
  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?
  - blattimwind 8y ago
    Grab framebuffer at refresh rate and measure the time until your end-of-test marker appears in the FB.
    - MaxBarraclough 8y ago
      That'd do it.
- mpweiher 8y ago
  A good stopwatch.
- ClashTheBunny 8y ago
  I think that https://pavelfatin.com/typometer/ 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.
- irq-1 8y ago
  I think this works: START=`date +%S.%N` && find ~ && echo $START && date +%S.%N

lake99 8y ago

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.

Avamander 8y ago

Please suggest better methods then.

MaxBarraclough 8y ago
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?
- blattimwind 8y ago
  Grab framebuffer at refresh rate and measure the time until your end-of-test marker appears in the FB.
  - MaxBarraclough 8y ago
    That'd do it.
mpweiher 8y ago
A good stopwatch.
ClashTheBunny 8y ago
I think that https://pavelfatin.com/typometer/ 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.
irq-1 8y ago
I think this works: START=`date +%S.%N` && find ~ && echo $START && date +%S.%N