After using iTerm2 as my daily driver for like a decade, and then trying out some of these other "fast" terminal emulators, I was amazed at how slow the experience in iTerm2 is. I even kept alacritty around as a second terminal for a while for cases when not having iTerm2 features wasn't a deal breaker, but eventually I just went back to iTerm2. I am still aware of how slow it is, and although I tolerate it, I wish it were as fast as some of the others.

You can see the speed difference with your eyes by joining a tmux session from different terminal emulators and doing operations that redraw the whole terminal, such as searching in a less pipe.

> eventually I just went back to iTerm2. I am still aware of how slow it is, and although I tolerate it, I wish it were as fast as some of the others

Indeed. It still has the best feature set of all the terminal emulators I tried, though, and I wish it worked on Linux.

I find Konsole very featureful and fast…

I see…

These days, I mostly use WezTerm on MacOS. And ocassionaly iTerm2.

iTerm2 is slow? Man I guess I'm not a heavy command line user. I mosty open 5 or 6 tabs. tmux? Very very rarely.

The slowness is noticeable often enough in simple typing latency, but there's definitely a spectrum as to how much people notice or find it frustrating. On the one end there's the people that won't use anything but xterm, while on the other there's people who don't care about the seconds of latency for some remote development setups.

Yes. It's common on at least Microsoft terminals to be waiting for the terminal to finish displaying the output it has been sent. I expect that it will be the same for many older terminal emulators.

Most older terminal emulators tends to do fairly well. E.g. on Linux, rxvt tends to be one of the fastest. Many older terminals tends to do well not least because many older terminals implements jump-scrolling properly (scroll multiple lines at a time before updating the screen if the rendering doesn't keep up) because there are even escape codes to turn that on/off.

There's a weird "bathtub curve" when it comes to terminal speed where the oldest tends to be well optimised in terms of tricks to minimise rendering, the newest all tend to concern themselves very much with rendering smart, but often miss the old-school tricks, and quite a few of the ones in the middle are just really naive about everything.

Spot on!

I’ve never been able to perceive the difference. I use iTerm2 and I can’t perceive how it could be faster.

Most of the time people only notice the slowness if they are in the habit of regularly letting huge amounts of output stream to the terminal, so it really depends on how you use your terminal. I agree with you - for me terminal speed was a solved issue in mid 1980's, and has not been an issue since.

> Are people frustrated by the latency of the incumbents

Yes. If you write code in vim as I do, terminal latency (snappiness) is very important. s a matter of fact, that's the main reason I paid attention to this project.

Ya, there was a very noticeable VImprovement (lol, sorry) switching from iTerm to Alacritty. I'd never heard of this project before, looks really interesting.

Seems to be a windows/mac problem. In Linux I've never really been bothered by it in at least 20 years

The speed of Gnome Terminal and Konsole on Linux along with Microsoft Terminal on Windows didn't bother me until I tried a couple of the newer faster terminals. Now all 3 seem slow to me.

It’s not a Windows/Mac thing. There are definitely slow terminal emulators for Linux as well. I’m quite sure you wouldn’t want xterm as your daily driver.

I use exactly that. It's fine for me and I'm very much a terminal first person.

Maybe people have extremely fancy shell setups? Perhaps it's a font thing that slows it down?

I just timed my xterm. I'm displaying about 2.3MB/s of characters. I really don't know what people are doing where this is slow - I don't think even Evelyn Wood claimed to read at that speed (also it's worth noting I'm tech-old and grew up on 2400/9600 baud so this will forever calibrate my expectations at some deep subliminal level)

Basically here was my test

    $ dd if=/dev/urandom bs=10M count=1 | hexdump -C > /tmp/test
    $ ls -l /tmp/test
    -rw-r--r-- 1 chris chris 51773449 Oct  8 09:32 /tmp/test
    $ time cat /tmp/test

    ... wait wait wait ....

    51773449 / (total time) / (2^20)
   

Now this of course depends on the size of the window. I'm on a 4320x3840 dual 4k monitor and the window geometry was 1334x928 for this test.

I acknowledge this computer (i7-8650U ~ 2018 thinkpad) is capable of faster output but the xterm featureset is vaaassstt (albeit extremely complicated) and I've found the other terminals to be lacking.

2MB/s is glacial. Your computer is very fast, it should be able to print over 1GB/s without breaking a sweat.

Casey Muratori demonstrated this with his refterm project. It seems like a lot of interest in making fast terminals has followed from that.

Why do I care? I can't read things that fast

This isn't rhetorical. I can't answer the question

To be honest, refterm was a bad idea to begin with. It's not a terminal, and it eventually also stated that in its README.md. Not to mention, that you - by definition - can't compare apples with pies. refterm is not a terminal and thus cannot be compared with a terminal WRT speed. It simply prove a point on rendering speed, at a cost of breaking a lot of the rules a terminal emulator has to obey to. Most notably is `DECAWM` (DEC Auto-Wrap Mode) that was not properly implemented. The author once stated in a Twitch stream that he simply didn't understand that and thus skipped that part. However, that is the part where it will get complex (and thus slow) if you want to get it right for non-trivial US-ASCII characters, such as complex grapheme clusters (family Emoji most interestingly) or even VS16 (variation selector changing the width of the base code point from narrow to wide). The latter point isn't standardized by DEC anyways, but the younger terminals all try to make the terminal more appealing to the younger Unicode crowd that do expect complex Unicode to render "just fine" (or "as fine as it gets"). refterm also had a hard coded 4k line length limit and just hard-cut off there instead of properly counting for the wrap.

TL;DR refterm (while positively inspirational to a few) was harmful to the terminal community, because it was fooling a lot of people with false metrics that the users simply believed in, without questioning.

I use xterm. Seems fine. Not sure what I'm missing I guess but I get my work done.

On Windows, yes. Not on Mac or Linux though.

Short answer: yes.

Longer answer, there are diminishing returns, but speed definitely is a selling point. A terminal being slow is not necessarily something you notice straight away (if the software is competent in the first place; a lot of them are not). However, testing a new one with a lower latency and fewer buffering issues is when you feel it, and then it is difficult to go back.

> Are people frustrated by the latency of the incumbents?

Not me, no. And I'm not even frustrated by pretty much anything. I have some Cygwin SSH sessions on the go and I'm running 'screen' in those terminals. It works and has done since the '90s.

Latency doesn't bother me too much, but throughput can really matter if I'm running a particularly verbose command. Often program speed is limited by how fast the terminal is able to clear the stdout pipe. This is especially true when running commands inside emacs "build" window (which is running who-knows-how-many regexs). If it's more than ~10,000 lines long then an instant command can be slowed down to more than 10 seconds.

I only care about latency from pressing Ctrl+alt+t to typing the first char of the command.

xfce4-terminal does just fine for this. So I just use that.

Long term Gnome Terminal user, I recently tried Alacritty, ugh, massive difference. Went back to Gnome after a couple of days. Like typing through molasses. Terminals can be slow.