If you’re sensitive to latency and run Linux, try hitting Ctrl-Alt-F1, and do a little work in console mode at the terminal. (Ctrl-Alt-F7 to get back.)
For me this is a great illustration of how much latency there is in the GUI. Not sure if everyone can feel it, but to me console mode is more immediate and less “stuffy”.
I notice this as well - the linux console feels better, in the same way that playing CS:GO without the overhead of a desktop compositor feels more immediate.
I’ve also noticed that tmux adds a lot of latency to vim in the terminal, so I’ve been running gvim or nvim-qt recently.
Oh, man, I’ve seen that but didn’t quite put it together (or didn’t think to look for a setting to adjust). The delay to get an ESC to “stick” was crazy long, with the result that I couldn’t get out of insert mode without resorting to press escape, sit on hands, count to six, resume typing.
There is a whole lot more calculations to do in a graphical environment: align the character on the table, pick the font, compute font substitution (missing glyph get rendered with other fonts), render every glyph from their vectorial format, calculating antialiasing and hinting… and all of this on top of a framework, while it is either non-existant or built-in for text interfaces.
A good compromise may be bitmap terminal (blit, acme, sam…).
I nominate st, the suckless terminal - http://st.suckless.org/ - It might not always the absolute fastest terminal (I’ve not tested it), and it might not have every feature anyone could ever (not) want like SIXEL and ReGIS Tektronix 4014 graphics, configurable logging, URL launching, user-tweakable selection behaviors and all that jazz that exists in xterm, but it is refreshingly simple, lightweight, and fast.
st becomes a whole lot less simple and lightweight once you configure your shell to always spawn a new tmux session for every terminal just to get scrollback. I can appreciate simplicity, but there comes a point where the system becomes a lot more complex because one tool is a bit too simple.
Since we’re discussing efficiency, tmux scrolling is also inefficient. All the data in the back buffer needs to be resent to xterm. If I’m on a bad network link, I’ll sometimes start another connection, sans tmux, to run a command so that all the output gets saved in my local buffer and I can scroll it without latency.
This is a valid point which 5 years of mosh use has made me forget about - for those who are not aware, with mosh, you aren’t sending data to the terminal as a stream of data, but instead synchronizing an “image” of the current terminal state and display, so there was never any “past” data to scroll back on.
I am sort of shocked that anyone uses the terminal scroll back in 2017 - I’ve been using tmux for almost 10 years now, but I was using xterm in combination with screen since the early 1990’s X11R4 days and always had my systems configured this way for almost 30 years. I find using a terminal multiplexer actually removes complexity and massively increases productivity and I have no idea how I’d operate without one.
If I was using some floating window manager, having tmux for tiling would make sense. I use i3, so my window manager handles tiling in a much more flexible way than tmux ever could (not through any fault of tmux, it just cannot tile graphical applications), so tmux is mostly unnecessary unless I need some of the features related to multiplexing or persistent sessions.
When I tried “alternative” OS’s in VM’s, they usually opened opened apps or responded to my typing instantly. They were that much faster in VM’s than the Linux system they ran on which was bare metal. My Windows systems were more responsive, too, back when I used them. I think it’s just the implementation in these GUI’s slowing things down that much.
This talk blew my mind and made me feel like a terrible engineer. He’s talking about end-to-end latency in VR, which actually has a commercial motivation because VR products with high latency will make you sick. (this obviously doesn’t happen with shells and terminals!)
He’s talking about the buffering and filtering at every step of the way. And it’s not just software – sensors have their own controllers to do filtering, which requires buffering, before your OS kernel can even SEE the the first byte, let alone user space. On the other side, display devices and audio output devices also do nontrivial processing after you’ve sent them your data.
It’s an integrated hardware/software problem and Carmack is great at explaining it! It’s a dense, long-ish talk, but worth it.
On HN, alacritty’s author states that they have a PR open to implement scrolling, and are considering it, as it doesn’t seem to impact speed much. Wonder what that’d like compared to the “with tmux” speed in TFA.
Why doesn’t it support scrollback? Alacritty’s original purpose was to provide a better experience when using tmux which already handled scrollback. The scope of this project has since expanded, and scrollback will eventually be added.
I noticed myself getting much less annoyed by terminal latency after having spent some time working on VMs located on the opposite side of the world (Britain to Australia) via ssh.
I played nethack on nethack.alt.org (US EC2) over a flaky GPRS/EDGE connection in Russia a few years ago :D (3G was supposed to be there but it dropped out sometimes)
If you’re sensitive to latency and run Linux, try hitting Ctrl-Alt-F1, and do a little work in console mode at the terminal. (Ctrl-Alt-F7 to get back.)
For me this is a great illustration of how much latency there is in the GUI. Not sure if everyone can feel it, but to me console mode is more immediate and less “stuffy”.
(copy of HN comment)
I notice this as well - the linux console feels better, in the same way that playing CS:GO without the overhead of a desktop compositor feels more immediate.
I’ve also noticed that tmux adds a lot of latency to vim in the terminal, so I’ve been running gvim or nvim-qt recently.
Tmux adds a lot of latency? Especially after pressing ESC in Neovim? Try
set -g escape-time 10in your~/.tmux.confhttps://github.com/neovim/neovim/wiki/FAQ#esc-in-tmux-or-gnu-screen-is-delayed
Oh, man, I’ve seen that but didn’t quite put it together (or didn’t think to look for a setting to adjust). The delay to get an ESC to “stick” was crazy long, with the result that I couldn’t get out of insert mode without resorting to press escape, sit on hands, count to six, resume typing.
There is a whole lot more calculations to do in a graphical environment: align the character on the table, pick the font, compute font substitution (missing glyph get rendered with other fonts), render every glyph from their vectorial format, calculating antialiasing and hinting… and all of this on top of a framework, while it is either non-existant or built-in for text interfaces.
A good compromise may be bitmap terminal (blit, acme, sam…).
Happily using bitmap fonts with xterm.
Drawing vector fonts is so darn slow that most things that do it at all will cache the rendered glyphs.
I nominate st, the suckless terminal - http://st.suckless.org/ - It might not always the absolute fastest terminal (I’ve not tested it), and it might not have every feature anyone could ever (not) want like SIXEL and ReGIS Tektronix 4014 graphics, configurable logging, URL launching, user-tweakable selection behaviors and all that jazz that exists in xterm, but it is refreshingly simple, lightweight, and fast.
And I like this term for this reason. The only 2 os I could not compile it so far is Windows and Android.
st becomes a whole lot less simple and lightweight once you configure your shell to always spawn a new tmux session for every terminal just to get scrollback. I can appreciate simplicity, but there comes a point where the system becomes a lot more complex because one tool is a bit too simple.
Since we’re discussing efficiency, tmux scrolling is also inefficient. All the data in the back buffer needs to be resent to xterm. If I’m on a bad network link, I’ll sometimes start another connection, sans tmux, to run a command so that all the output gets saved in my local buffer and I can scroll it without latency.
This is a valid point which 5 years of mosh use has made me forget about - for those who are not aware, with mosh, you aren’t sending data to the terminal as a stream of data, but instead synchronizing an “image” of the current terminal state and display, so there was never any “past” data to scroll back on.
I am sort of shocked that anyone uses the terminal scroll back in 2017 - I’ve been using tmux for almost 10 years now, but I was using xterm in combination with screen since the early 1990’s X11R4 days and always had my systems configured this way for almost 30 years. I find using a terminal multiplexer actually removes complexity and massively increases productivity and I have no idea how I’d operate without one.
If I was using some floating window manager, having tmux for tiling would make sense. I use i3, so my window manager handles tiling in a much more flexible way than tmux ever could (not through any fault of tmux, it just cannot tile graphical applications), so tmux is mostly unnecessary unless I need some of the features related to multiplexing or persistent sessions.
When I tried “alternative” OS’s in VM’s, they usually opened opened apps or responded to my typing instantly. They were that much faster in VM’s than the Linux system they ran on which was bare metal. My Windows systems were more responsive, too, back when I used them. I think it’s just the implementation in these GUI’s slowing things down that much.
If you care about end-to-end latency, I highly recommend this talk by John Carmack:
https://www.youtube.com/watch?v=lHLpKzUxjGk
This talk blew my mind and made me feel like a terrible engineer. He’s talking about end-to-end latency in VR, which actually has a commercial motivation because VR products with high latency will make you sick. (this obviously doesn’t happen with shells and terminals!)
He’s talking about the buffering and filtering at every step of the way. And it’s not just software – sensors have their own controllers to do filtering, which requires buffering, before your OS kernel can even SEE the the first byte, let alone user space. On the other side, display devices and audio output devices also do nontrivial processing after you’ve sent them your data.
It’s an integrated hardware/software problem and Carmack is great at explaining it! It’s a dense, long-ish talk, but worth it.
(copy of HN comment)
How can st be so slow? It’s tiny and hardly does anything!
Later in the article, the author mentions that it was running on a mac under xquartz, which may explain the latency.
There is a
linux-stentry in the graphs which is significantly fasterOn HN, alacritty’s author states that they have a PR open to implement scrolling, and are considering it, as it doesn’t seem to impact speed much. Wonder what that’d like compared to the “with tmux” speed in TFA.
The readme says it directly:
With keybindings-based interface, your interface changes a lot while you do stuff, so latency is a pain.
With REPL-based interface (a shell), you can type a whole sentence without refresh, it is still manageable.
If you have a GUI, latency is terrible.
I noticed myself getting much less annoyed by terminal latency after having spent some time working on VMs located on the opposite side of the world (Britain to Australia) via ssh.
I played nethack on nethack.alt.org (US EC2) over a flaky GPRS/EDGE connection in Russia a few years ago :D (3G was supposed to be there but it dropped out sometimes)