Alacritty gets scrollback, publishes benchmarks(jwilm.io)
jwilm.io
Alacritty gets scrollback, publishes benchmarks
https://jwilm.io/blog/alacritty-lands-scrollback/
34 comments
"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
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
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.
All that said, I'm glad to hear there's a plan on the latency front.
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.
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.
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.
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?
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
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
This is actually enabled by default unless you disable it. No extra code needed, unless the macOS implementation conflicts with yours.
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.
We haven't intentionally opted out of this that I know of, we just didn't start Alacritty from an XCode project on macOS.
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.
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.
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.
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
If you want notifications on any developments here, please subscribe to this GitHub issue: https://github.com/jwilm/alacritty/issues/673
Thanks, I'll definitely be looking forward to any improvements on that!
I'm really happy to see all the hard work come together on this. I think the project has a great new feature.
Author here; I'm happy to answer any questions!
Not so much a question, but I wanted to thank you for the project. It's hit a sweet spot of configurability, stability, and performance for me, all without the baggage or caveats alternatives have. It's been my terminal of choice for a while now. Keep up the good work.
How did you choose the terminals to benchmark against? What about xterm or gnome-terminal or powershell or whatever?
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.
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.
I hate the moment when I lose something in history so I've set my xfce4-terminal to 250k lines which was always enough so I've tried to set scrollback history to that number. Alacritty allocated 1.4GBs during startup while Xfce can keep it within 20MBs. Any plans to allocate memory a bit less aggressively if such high number is used? Sure, without scrollbar it's kinda pointless anyway but when it gets implemented it can be useful.
Thank you
Thank you very much. It's a delightful experience I have on all my machines.
Thanks for the updates! I'm compiling it now...
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.
What possible use cases where such high scrollback speeds could be useful?
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 [1] https://hyper.is/
[0] https://news.ycombinator.com/item?id=17635869 [1] https://hyper.is/
> 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.
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.
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.
It is certainly not a bad thing, was just asking out of curiosity
Sorry I did not word that properly, I did not meant to sound aggressive, what I meant to say was that the high performance characteristic is nice to have even if there is little use for it. It is a breath of fresh air in the modern trend of building everything on electron. Having the option for a x-platform terminal emulator with a modern code base is an added bonus! One thing that I forgot to mention was that I particularly love Joe's approach to its development, (similar to suck less approach) changes and features are added only if they do not negatively impact performance (in a significant way) and if you do not want to enable them they can be disabled during build, completely removing them form the compiled program.
Also vim performance is really great inside VMs in Alacritty on my 6th gen core i5 laptop :)
Also vim performance is really great inside VMs in Alacritty on my 6th gen core i5 laptop :)
There is a difference in performance in other Terminals?
Edit: oh, just saw your other comment
Edit: oh, just saw your other comment
[1]: https://danluu.com/term-latency/
[2]: https://lwn.net/Articles/751763/