[amelius]

Yes, its README explicitly says:

> Alacritty is the fastest terminal emulator in existence. Using the GPU for rendering enables optimizations that simply aren't possible in other emulators.

I wonder though why people need fast terminal emulators (?) I'm using "xterm" and I haven't found any issues with speed.

[mtrovo]

I'm using only alacritty for the past year and at least on MacOS the rendering latency is in another level. The response is super fast while scrolling through text on less or vim, changing windows on tmux seems to happen instantly, even typing seems to happen without a delay compared to iTerm or Terminal.

One thing that I thought would justify this is that they don't support scrolling text by themselves and to have it you're required to rely on tmux or screen.

[wezm]

Alacritty supports scrolling as of version 0.2.0 https://github.com/jwilm/alacritty/releases/tag/v0.2.0

[jstimpfle]

Coincidentally xterm is the fastest I know, in particular if you use bitmap fonts. Gnome-Terminal for instance feels rather sluggish.

[craftyguy]

A while back LWN did a great comparison of terminal emulators, performance was one aspect they looked at: https://lwn.net/Articles/751763/

[jstimpfle]

Always nice to see one's own subjective experiences backed up by hard measurements :-)

[rancor]

In my experience, urxvt is both faster and uses less memory than xterm by a good margin, although there's not such an appreciable difference on a modern system. Gnome Terminal, on the other hand, is beyond slow, far worse than the still slow but acceptable Konsole.

[emmelaich]

You can read stuff as the text scrolls flying by.

Without acceleration it's a blur.

[dzdt]

I sometimes dump megabytes of text to stdout/stderr as a way of monitoring or debugging long-running computations. Terminal speed matters then.

[amelius]

In those cases, I usually redirect the output to a file, so I can search through it.

Another approach is to run "screen", which has several advantages: (1) not all text needs to be written to the terminal, only the text when you actually look, (2) you can open the computation on a different computer later (e.g. perhaps at home to check if everything is ok), and (3) if you accidentally close the terminal the computation keeps running.

In both cases, my terminal emulator does not need to be fast, really.

My biggest issue with speed in the terminal comes from network latency (which is difficult to fix).

[eru]

tmux is a modern alternative to screen.

Oh, and while you are at it, have a look at mosh as well. Mosh bills itself as the ssh alternative for mobile, intermittent connections but it does take the idea of 'not all text needs to be written to the terminal, only the text when you actually look' even further.

Mosh also has lots of network latency hiding tricks up its sleeve.

[emmelaich]

I bet you could implement a fast-enough terminal in QUIC, and keep the idea of non-permanent connection.

[sime2009]

Rendering speed shouldn't matter in this case because the terminal shouldn't be trying to render every single line which is sent to it. The terminal should just process the stream and commands, and real updates to the screen.