Hacker News Reader

Comment by sime2009 | Hacker News Reader

sime2009

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.

View on HN

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.

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

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.

Reply on news.ycombinator.com