[HN Gopher] Measured typing latency of popular terminal emulators
___________________________________________________________________
Measured typing latency of popular terminal emulators
Author : klaussilveira
Score : 24 points
Date : 2023-05-03 20:54 UTC (2 hours ago)
(HTM) web link (tomscii.sig7.se)
(TXT) w3m dump (tomscii.sig7.se)
| throwaway280382 wrote:
| For terminal aficionados here, which terminal works well with
| chatGPT ? I want chatGPT to predict my next keystroke, based on
| my previous commands I typed.
| pmontra wrote:
| > xterm does direct rendering via Xlib, which is the primary
| reason it can be so fast in responding to user input. This is
| also the reason why its throughput is, on the other hand, rather
| poor.
|
| What's throughput in this case?
| ninkendo wrote:
| My guess is the rate at which stdout from a process shows up in
| the terminal?
|
| I think Terminal.app on macOS is likely the inverse of this...
| it likely has a fair amount of input lag, but holy moly can it
| handle a lot of output being dumped at once without breaking a
| sweat.
| adamwk wrote:
| I thought terminal.app has very short latency, looking back
| at the benchmarks written about here https://danluu.com/term-
| latency/. Terminal.app's latency measures around 5ms beating
| most other terminals. (It's a shame it still doesn't support
| true color.)
| smlavine wrote:
| I use st daily. Having it open side by side with xterm (and also,
| by the way, typing out this comment in Firefox), I don't see how
| the differences mentioned in the article are relevant to the user
| experience. The character appears before my finger lifts from the
| key. Perhaps improvement /could/ be made, but I don't think it'd
| be worth it. There are other things to prioritize.
|
| It is interesting to see the numbers laid out like this, though.
| rightbyte wrote:
| I wonder if your keyboard latency dominates?
|
| In older games like CS 1.6 I believe I could feel the
| difference between say 10 and 40 ms ping. Maybe PS/2 keyboards
| were faster. I got the feeling older computers were way faster
| to respond ... but I might remember wrong.
| scottlamb wrote:
| > I got the feeling older computers were way faster to
| respond ... but I might remember wrong
|
| I don't know the specific devices you've been using over
| time, but in general the measurements in the following
| article back up your memory: https://danluu.com/input-lag/
| mprovost wrote:
| You remember... right. The Apple 2e blows away modern
| computers (in terms of latency).
|
| https://danluu.com/input-lag/
| lasr_velocirptr wrote:
| PS/2 Keyboards are faster than a USB keyboard with slow-speed
| negotiation with the host computer but for USB keyboards with
| high speed negotiation, they are at par[1]
|
| [1] https://www.youtube.com/watch?v=wdgULBpRoXk&t=1766s
| 0x457 wrote:
| I think it's more about consistency. If delay is consistent,
| you get used to it, but if it's all over the place it's more
| noticeable.
|
| I prefer to cap FPS in games for the same reason, if my PC
| can't deliver consistent frame rate.
| wmf wrote:
| Software latency measurement consistently understates latency
| which magnifies 1-2 frame differences. Unfortunately, camera-
| based measurement is a lot more work.
| snazz wrote:
| There's an iPhone app called Is It Snappy that records in slow
| motion and makes it pretty easy. I think the camera maxes out
| at 240 fps so it's not perfect but it lets you measure true
| end-to-end latency.
| philjohn wrote:
| Would be great to see Wezterm, it's always felt snappy, and Wez
| is a damn smart cookie.
| nathanwh wrote:
| Alacritty being so slow is surprising to me here. I only use it
| on macOS, but it feels faster than kitty when I'm looking at
| application logs scrolling quickly across the screen. Perhaps
| responding to typing events has different latency than tailing a
| log file or listening to stdout?
| the_jeremy wrote:
| The latencies are different, and kitty is slower at this
| because the author doesn't care about huge output[0]:
|
| > Some people have asked why kitty does not perform better than
| terminal XXX in the test of sinking large amounts of data, such
| as catting a large text file. The answer is because this is not
| a goal for kitty. kitty deliberately throttles input parsing
| and output rendering to minimize resource usage while still
| being able to sink output faster than any real world program
| can produce it. Reducing CPU usage, and hence battery drain
| while achieving instant response times and smooth scrolling to
| a human eye is a far more important goal.
|
| 0: https://sw.kovidgoyal.net/kitty/performance/
| wmf wrote:
| This sounds backwards from both an energy perspective and
| human factors perspective. I don't understand the throughput
| vs. smooth scrolling tradeoff though.
| DiabloD3 wrote:
| Summary:
|
| 1) Extremely fast GPU-accelerated terminals have a latency of
| slightly more than one frame due to only rendering once per frame
| (for performance and latency reasons).
|
| 2) Gnome-terminal sucks.
|
| 3) Old school terminals, like xterm, are extremely slow in
| practice, but look very fast on benchmarks like this, as they
| render on TTY input and do not wait (thus wasting time and
| latency rendering unseen changes).
|
| 4) This article is old, and misses out a lot of optimization work
| that has occurred on Alacritty.
|
| 5) The author of this article has a 60hz monitor. These numbers
| would be unreproducable on higher refresh monitors.
___________________________________________________________________
(page generated 2023-05-03 23:00 UTC)