
Terminal latency (2017) - andyjpb
https://danluu.com/term-latency/
======
romwell
As a keyboard player, I can tell you that anything over 10ms latency
noticeably degrades the experience. 100ms of keypress-to-sound latency makes
the instrument unplayable.

Your ears will detect very small latencies; offset something just by 1-2ms,
and you get an echo feel; 50ms will be off-beat.

(Organ players have to deal with that kind of latency on their instrument[1],
but it's a hard skill to learn, and limits the music that can be performed on
the instrument. Say, following a drummer is out of the question.)

Why people tolerate huge amounts of unnecessary latency is beyond me. And
_everything_ is laggy these days.

Except MIDI/audio setups, that is. And even in that scene, Android got a low-
latency API only last year.

I say, the decade of 2020 will be not about increasing _performance_ , but
decreasing the goddamn _latency_ down to unnoticeable levels. Or I really hope
so.

[1][https://music.stackexchange.com/questions/30454/how-does-
a-p...](https://music.stackexchange.com/questions/30454/how-does-a-pipe-
organist-deal-with-latency-or-delay)

~~~
squarefoot
"As a keyboard player, I can tell you that anything over 10ms latency
noticeably degrades the experience."

Which explains why unless I missed some new development, there's no way
professional music can be played live on any Android based product. By music I
mean music, not triggering prerecorded loops, a thing which could be done on a
50+ years old Mellotron as well. I'm 100% sure Java is to blame: low latency
and virtual machines don't mix well.

~~~
brian_cloutier
> I'm 100% sure Java is to blame

I shouldn't but I will anyway: People who are 100% sure of things are
generally wrong and this case is no exception.

I'm being facetious here but what if I told you that nearly all machines are
virtual machines? Your CPU doesn't really execute instructions, it
_interprets_ them by first translating them to microcode.

There's nothing inherent to the idea of not coding directly on the lowest
level possible which forces your programs to have bad performance. Zero-cost
abstractions really do exist.

I mean, Erlang uses a virtual machine called BEAM, erlang programs sit at a
remarkably high level of abstraction, and it's not like erlang systems are
known for their chronically high latency.

The Android Runtime also compiles applications before running them [1]. The
instructions being run are native code in elf files [2].

Certainly Android has had latency issues, and I'm no fan of Java, but that was
more of an architectural thing than a Java-Is-Such-A-Bad-Tool-Lol thing.

[1]
[https://source.android.com/devices/tech/dalvik](https://source.android.com/devices/tech/dalvik)
[2] [https://stackoverflow.com/questions/26254538/difference-
betw...](https://stackoverflow.com/questions/26254538/difference-between-
dexopt-and-dex2oat/26263071#26263071)

~~~
rayiner
> I'm being facetious here but what if I told you that nearly all machines are
> virtual machines? Your CPU doesn't really execute instructions, it
> interprets them by first translating them to microcode.

Well that’s not true.

~~~
Phrodo_00
[https://en.wikipedia.org/wiki/Microcode](https://en.wikipedia.org/wiki/Microcode)

------
mrob
libvte is a major offender here. It's used in several popular terminal
emulators, and it's deliberately capped at approximately 40fps[0], which means
on a 60Hz display you'll sometimes get an additional frame of latency, and not
even predictably because the timing is so uneven.

Set your keyboard autorepeat to 60Hz, hold down a key in a libvte-based
terminal, and watch how bad it is. Now try again with xterm and see what it's
supposed to be like. I can only assume the slow update is some misguided
attempt at power saving.

[0]
[https://github.com/GNOME/vte/blob/master/src/vte.cc#L10547](https://github.com/GNOME/vte/blob/master/src/vte.cc#L10547)

~~~
swiley
People keep knocking xterm but honestly it still is probably the best and most
complete terminal emulator.

~~~
snazz
It also has the awesome Secure Keyboard feature, which I haven’t yet seen
anywhere else.

~~~
lelf
MacOS Terminal.app

------
nickjj
Too bad they didn't measure xterm. That one has always felt the best to me on
a native Linux system by a large margin.

Also Microsft's default WSL terminal (ubuntu.exe if you happen to be running
Ubuntu WSL) is a lot faster than anything else I tried on Windows. I suppose
that's what you get for using a low level UI API that's optimized for
performance. Its input latency is lower than any other app on Windows.

Back in December I did a Windows terminal review at:
[https://nickjanetakis.com/blog/conemu-vs-hyper-vs-
terminus-v...](https://nickjanetakis.com/blog/conemu-vs-hyper-vs-terminus-vs-
mobaxterm-terminator-vs-ubuntu-wsl)

There's no scientific measurements on input latency but input latency is
something I pay a lot of attention to, especially considering all you do is
type into a terminal. It is the most important thing IMO. The TL;DR is the
default WSL terminal is a lot better than anything else for low latency, but
WSLtty is what I use personally due to it being more configurable while still
being OK'ish for latency. Hyper and Terminus were the 2 worst performing
terminals in both input latency and having UI bugs that made the terminal
unusable for day to day usage (both Electron apps).

~~~
PascLeRasc
Did you do any modifications to the WSL default? It's by far the slowest
program on my work computer, like multiple seconds of typing latency at times.
It's disgusting to use. Hyper is a bit better but it's obvious Windows wasn't
designed by people who care about minor details like typing latency.

~~~
nickjj
Nope. I just launched ubuntu.exe running Ubuntu 18.04 WSL on Windows 10 Pro
latest stable release and it was the fastest terminal I ever used besides
xterm on native Linux.

I do have Windows defender disabled. I'm not sure if it scans every key press
though, but it will bring WSL's output to a grinding halt.

I use WSL / wsltty / tmux / terminal Vim (in WSL) as my primary dev
environment. It's really solid, even with 1.5mb to 5mb markdown files. Vim
uses about 8mb of RAM and a few % of CPU when typing. VSCode used 800MB of RAM
and 50%+ of my CPU to open and idle in the same markdown file with 65%+ CPU
load when typing.

------
nxrabl
(2017)

Previous discussion:
[https://news.ycombinator.com/item?id=14798211](https://news.ycombinator.com/item?id=14798211)

~~~
sevensor
I'd love to see a followup study. GPU based terminal emulators (alacritty,
kitty) have evolved a lot over the last two years.

~~~
swiley
My personal experience with GPU accelerated GUIs is that latency is always
worse.

Drawing text is something that the cpu is pretty good at and the GPU just
means more back and forth over the buss, more driver coupling, more weird
libraries.

~~~
raphlinus
I think you're right about GPU tending to have worse latency, but I think it's
because that's the way the swap chain is set up and the use of blocking
present calls. I've been studying this and am pretty sure I know how to make
low latency on Windows work, mostly it's following the advice in [1]. If you
do it right, then on modern hardware, DirectFlip kicks in and that saves you
an additional frame that would ordinarily be eaten by the compositor. I plan
to measure this at some point in the not too distant future, or would be happy
to mentor somebody interested in taking it on.

[1]: [https://devblogs.microsoft.com/directx/dxgi-flip-
model/](https://devblogs.microsoft.com/directx/dxgi-flip-model/)

------
macbookcabler
It would be interesting to see an updated test. Since this report, multiple
apps have undergone speed overhauls. The latest version of Hyper, for example,
dropped DOM rendering in favor of Canvas/WebGL.

That being said, there is a major difference in perceived speed working with
terminals over a GUI like in macOS versus something with fewer layers. I
hooked up a Raspberry Pi to do some vim editing using Raspbian Stretch Lite
and it felt like editing on a supercomputer (right up until I needed to
compile something).

~~~
matt4077
The only time I ever noticed a difference in input lag was when I had to
fumble my way through the UEFI console.

I had no idea what I was doing, but the speed was eerie.

~~~
dfox
This is common for anything that emulates text terminal on highres-ish
graphical mode using common denominator VGA/VESA interfaces without any HW
acceleration whatsoever (and also often with banked framebuffer).

By the way, on 4k monitor you can discern that grub2 draws its menu from
bottom up as it takes second or so.

Linux FB console is significantly faster but still scrolling (ie. fullscreen
redraw) is noticeably CPU intensive.

------
ksec
iPhone 6s Touch Screen had ~40ms end to end latency, it was good but wished it
was better.*

The iPhone XS had about 40 as well, but the iPhone XR had 60ms+ and in some
case closing in to 80ms. ( It was 60ms + 10+ from Display if I remember
correctly )

I know it is a hard to sell "figure", but I wish Apple could find a way to
market this, and improve on it. The Apple Pencil 2 and Pro Motion, are still
no where close to real time. It still feels lag, or Jank.

Note: I try to Google for the source but unfortunately nothing came up.

Edit: The only thing I got was this Chinese Site with a Table of input
latency.
[http://bbs.nga.cn/read.php?tid=16347225&page=1](http://bbs.nga.cn/read.php?tid=16347225&page=1)

~~~
nickpsecurity
"I know it is a hard to sell "figure", but I wish Apple could find a way to
market this"

Blackberry did that with the Playbook pitting it against iPads. They showed it
was more responsive by having a video game, a browser, and other stuff running
with no lag. Apple could similarly highlight faster response time.

------
gnachman
As mentioned, this is somewhat out of date. iTerm2 has gotten a GPU renderer
since then, which should reduce the latency. Unfortunately I can't get
typometer to work. I guess it's because it's not requesting the right
permissions on macOS 10.14.

~~~
acdha
If you have an iPhone, [http://isitsnappy.com/](http://isitsnappy.com/) is
very easy to test with

------
dmitriid
Throw in things like text/syntax highlighting, autocomplete, search etc., and
100ms latency will be a dream (speaking as oh-my-zsh user).

Also: fancy fonts and ligatures

~~~
mruts
Is zsh slower than bash or ksh on terminals?

~~~
kelp
I think op is mostly referring to how zsh users often load it up with
extensions to do fancy completions, and fancy prompts requiring special fonts
and doing lots of things like showing current git branch. It can add some
latency!

~~~
dmitriid
You've just described my situation :)

------
mirimir
I spend lots of time on remote servers and VPS with ssh via Tor. So I'm used
to ~500 msec latency.

But hitting VirtualBox VMs via VRDP via Tor, that can bring me to tears.
Installing Debian, say, is fine. Then you try to login.

    
    
        debian login: uuuss
        debian login: usssss
        debian login: uuus
    

And if you get to password, it's far worse, because you can't see what you've
typed. So I'd set user as "x" and its password as "z". And once I'd logged in,
do:

    
    
        setterm -repeat off
        setterm -repeat off >> /etc/issue
    

But then there's the joy of using GUIs. Mouse pointers with ~500 msec or more
latency are crazy making.

~~~
toastal
This is where mosh ([https://mosh.org/](https://mosh.org/)) really helps

~~~
mirimir
Thanks.

Except that Tor doesn't route UDP :(

Could do mosh via tinc via Tor, though. I'll try it.

------
snazz
Considering its simplicity, I wonder why st fared so poorly. Also, I’m
surprised that eshell did well on the latency part, since it sometimes feels
laggy (which could be due to its reimplementation of basic Unix tools in
elisp).

~~~
jcelerier
> Considering its simplicity, I wonder why st fared so poorly.

I don't understand why in earth you would expect simple solutions to be fast.
Most very fast software need some level of complexity in order to special-case
for the fast platform primitives. See for instance glibc which is _not simple_
when compared to musl but also rolls over it in benchmarks, because it uses
many state of the art algorithms and many architecture-specific optimizations.

~~~
tngranados
I think he means that st is simple regarding its features not its
implementation (which I know nothing about).

------
sagebird
I am curious how hn would construct a program which tried to minimize the
latency of "simplest" test possible. Lets say -- press the space bar and the
pixel at top right of screen turns green.

I used to use nasm on a dos machine - where it was possible to write a rather
straightforward assembly program that would take a keypress and update a pixel
-- but I am not sure how abstract/layered graphics stacks are on operating
systems these days -- IE -- what is the simplest/low latency method to tell a
computer to flip an pixel? SDL?

~~~
nickjj
A few months ago I asked the MS devs why their default WSL terminal felt
incredibly responsive and they replied with a ton of details.

You can read the thread here:
[https://github.com/Microsoft/console/issues/327](https://github.com/Microsoft/console/issues/327)

~~~
Dahoon
While the reply is great I feel it is missing the point a bit. The reason it
feels so fast is IMO because everything else is so slow. Look at the numbers
in below link (near the bottom). Windows 10 is _extremely slow_. Linux is
often twice as fast with the same hardware and the same software. Why they
still haven't fixed it is beyond me.

EDIT. Doh, forgot the link.

[http://isitsnappy.com/](http://isitsnappy.com/)

~~~
nickjj
> Linux is often twice as fast with the same hardware and the same software.
> Why they still haven't fixed it is beyond me.

Linux is no different. Gnome terminal has a ton of input latency compared to
xterm. It's like night and day. A lot of graphical apps in Linux have added
input latency just like Windows. It's due to layers of UI abstractions and
frameworks (the same as Windows but different UI toolkits of course).

That links just shows that VSCode and Atom are both horrendously bad for input
latency on any OS.

------
mikepurvis
Can confirm that latency on iTerm2 is awful. I tried it for a while at the
behest of a colleague and switched back to Terminal.app because I couldn't
bear the lag.

~~~
tomsmeding
How long ago did you test that? I recall trying out iTerm2 some time ago and
being appalled at the latency as well, but fairly recently I reconsidered it
and found it to be more than quick enough for my needs.

~~~
mikepurvis
At least a year ago, but my recollection is that it was context-dependent too.
Like, sometimes it was fine, and other times it wasn't, but it wasn't really
clear to me what caused the problem (wasn't obvious things like low memory or
having a giant scrollback).

------
esaym
I've used KDE's Konsole for 20+ years. How would I got about testing its
latency??

~~~
esaym
oh, I guess they were using
[https://github.com/pavelfatin/typometer](https://github.com/pavelfatin/typometer)
?

~~~
esaym
Looks like around 31ms:
[https://i.imgur.com/qHblAg1.png](https://i.imgur.com/qHblAg1.png) Good enough
for me I guess.

------
mruts
Why is xterm not included? It’s probably the most popular terminal on Linux.
It’s also noticeably laggy.

I’m surprised that eshell performance is so good. Maybe because it supports
less features than a standard terminal? I use Emacs and Elisp everyday and
both are dog slow. It’s unfortunate that they still haven’t managed to replace
the interpreter and bytecode compiler with a faster scheme compiler after all
this time.

As an aside, GNU projects seem broken in their management. Every project seems
to be run by some get off my lawn egomaniac. (ex RMS, Ulrich Drepper)

~~~
stonogo
> Why is xterm not included?

Because it doesn't run on a Mac. It was tested elsewhere though and found to
be among the quickest, so maybe your configuration is suboptimal.

> Every project seems to be run by some get off my lawn egomaniac. (ex RMS,
> Ulrich Drepper)

The list of projects currently run by that list of people comprises "emacs and
nothing else." Drepper left glibc maintainership many years ago and RMS has
not been actively involved in anything other than emacs for a similar duration
(aside from crippling gcc backend splitting).

~~~
yellowapple
Doesn't X11 ship with macOS (i.e. to run "legacy" Unix apps)? I could've sworn
I've used xterm before on it.

~~~
jki275
It doesn't ship on it anymore. It used to a number of years ago.

