[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/

[2]: 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

[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.