
Alacritty gets scrollback, publishes benchmarks - jwilm
https://jwilm.io/blog/alacritty-lands-scrollback/
======
mindB
These benchmarks miss the point in my opinion. When I'm choosing a terminal
emulator, beyond features, the one "performance" metric that I'm interested in
is latency; nothing else really affects my workflow (positively or
negatively). In the benchmarks I've seen of alacritty wrt latency[1][2], it
doesn't come out so well.

[1]: [https://danluu.com/term-latency/](https://danluu.com/term-latency/)

[2]: [https://lwn.net/Articles/751763/](https://lwn.net/Articles/751763/)

~~~
jwilm
"miss the point" feels a bit strong. Rather, I get the impression Alacritty's
values don't match your own values in a terminal emulator, and that's totally
OK. Historically, input latency hasn't been considered a big pain point by
most users.

That said, we do have a plan[1] to address this issue and be both high
throughput _and_ low-latency.

[1]:
[https://github.com/jwilm/alacritty/issues/673](https://github.com/jwilm/alacritty/issues/673)

~~~
mindB
Fair enough. :) I guess my stronger wording is because I don't understand
workflows where being able to dump vast quantities of text to the terminal
quickly is important. In general, a terminal emulator is for use by a human,
and humans can't really process info at the throughput rate of other terminal
emulators, much less the faster alacritty.

All that said, I'm glad to hear there's a plan on the latency front.

~~~
singingboyo
It's not ideal, but one flow I end up using at some points is tmux-as-grep.
Basically, something either gets dumped to terminal, and I use tmux's search.
So then, for a combo of reasons (some good, some bad) I cat files to terminal
on occasion, and I use tmux's search to find something in it.

The idea isn't that the I'm processing at the throughput rate of the emulator
- it's more that a low throughput rate delays when I can start actually
looking for something useful.

~~~
jimpudar
I've never understood this mentality. If you can dump something to the
terminal and use tmux search, you could just as easily use `less` which is
pretty much purpose built for this.

------
pcwalton
Regarding tabs, macOS has native tab support more or less built-in to the
windowing system—you can see this in action if you create a document-based app
in Xcode—but your app has to be structured in such as a way as to opt into it.
Have you considered opting into this or would you consider it contrary to the
project goals?

~~~
jwilm
The hardest part about supporting things like this on macOS is that they often
require a lot of additional code or a certain design whereas on Linux, a lot
of these features are provided by the window manager.

I don't consider it contrary to the project's goals if it's something that can
be done unobtrusively. Given your description, it sounds like this may be
something we could support easily. I filed #1544 to track this. Thanks for the
suggestion!

#1544:
[https://github.com/jwilm/alacritty/issues/1544](https://github.com/jwilm/alacritty/issues/1544)

~~~
saagarjha
This is actually enabled by default unless you disable it. No extra code
needed, unless the macOS implementation conflicts with yours.

~~~
jwilm
Thanks for this clarification. I don't see any reason we couldn't support this
given that info.

We haven't intentionally opted out of this that I know of, we just didn't
start Alacritty from an XCode project on macOS.

~~~
saagarjha
I've noticed you don't have anything in the menu bar. The option normally
appears under Window > Merge All Windows, which is inserted by default by the
Xcode template.

~~~
jwilm
Thanks for this additional feedback. It sounds like we should create an XCode
project from scratch to get many of the defaults and figure out how to bridge
this with our current implementation.

------
steinuil
Has the input latency improved any? I liked alacritty, but I switched to
mlterm after a while because the input latency was really bugging me.

~~~
jwilm
Thanks for this feedback! We haven't heard a ton of complaints about the input
latency, and comments like this help us to prioritize issues. This has been
mentioned in two discussions today, so perhaps it's time to address this.

If you want notifications on any developments here, please subscribe to this
GitHub issue:
[https://github.com/jwilm/alacritty/issues/673](https://github.com/jwilm/alacritty/issues/673)

~~~
steinuil
Thanks, I'll definitely be looking forward to any improvements on that!

------
nixpulvis
I'm really happy to see all the hard work come together on this. I think the
project has a great new feature.

------
jwilm
Author here; I'm happy to answer any questions!

~~~
Y_Y
How did you choose the terminals to benchmark against? What about xterm or
gnome-terminal or powershell or whatever?

~~~
jwilm
We tried to strike a balance between "commonly accepted as fast" terminal
emulators and coverage of "commonly used" terminal emulators. Termite gets us
libvte-based terminals (like gnome-terminal), urxvt is generally considered as
one of the fastest, and Kitty is another well-regarded GPU-accelerated
terminal emulator. On macOS, there's not nearly as many choices.

Ultimately, it would be great if we could benchmark against every terminal
emulator, but that can become a very time-consuming task. If there's another
emulator you feel should be included, we can consider it for future
updates/benchmarks.

~~~
billiob
You could try Terminology (I'm the main dev). It can be GPU-accelerated or
not.

~~~
jwilm
I didn't know that Terminology has GPU acceleration. I would be happy to
include this in the future!

------
aktau
This sounds great, especially the fact that v0.2 has much improved throughput
over v0.1 in most cases. I must however echo some other posters' sentiments:
latency is even more important than throughput, and alacritty's input latency
wasn't great last time I tested it (quite a while ago). Maybe it's been
improved too, though no mention of it in the post.

------
O_H_E
What possible use cases where such high scrollback speeds could be useful?

~~~
L0stLink
Performance is never a bad thing, even if I don't always need my terminal
emulator to be able to handle large amounts of text, there is nothing wrong
with having a light weight high performance (eventually cross platform,
hopefully) modern terminal emulator. I read a while back that implementing the
same in iterm2 (a popular macOS only terminal emulator) is challenging due to
past design decisions [0]. Certainly in a time where hyper terminal[1] (based
on electron) exists, I see no downside to having the option of Alacritty.

[0]
[https://news.ycombinator.com/item?id=17635869](https://news.ycombinator.com/item?id=17635869)
[1] [https://hyper.is/](https://hyper.is/)

~~~
nullify88
> Performance is never a bad thing

Depends on your priorities and what you are willing to sacrifice for it. High
bandwidth terminal emulators will cost CPU and battery life. I'd opt for
longer battery life.

The choice is nice to have though.

~~~
L0stLink
I agree! currently I run windows as my main OS precisely due to inferior
battery life on Linux. I only use Alacritty in minimal Linux VMs when they are
not running headless(as pseudo containers, I will be migrating fully to Linux
+ Docker soon). I normally only work with the VMs while plugged-in and because
Alacritty is not available for windows yet, have not used it much on battery
therefore I am not in a position to say anything about the battery impact. One
thing I have noticed is that it is noticeably slower to start on the same VM
as compared to XTerm but the VIM experience was better in Alacritty.

