Hacker News Reader

Comment by joncp | Hacker News Reader

Nice work!

I do wonder, however, whether people really have issues with perf on any terminal emulator in 2026

I’ve been living in Terminal.app / zsh / tmux / vim for 15 years and have never once thought “this is slower than I want.”

View on HN

To me, the most relevant aspect is the time it takes to open. I can't believe how slow the startup time in common linux distributions is by default, it's so annoying, by the time it opens I already forgot what I wanted to do. Alacritty has this cool feature where you only ever have to "open" a single terminal, whereas new windows can be created very efficiently with `alacritty msg create-window`, being forks of the initial window. It makes using my pc a lot more comfortable.

this is is not new. we have had factory model (forking the initial window) in terminal emulator since 1990s.

Also present in urxvt and kitty.

I'm using OpenBSD with xterm, and when I use something like `time xterm -e 'sh -c "echo 1; exit"'`, it says 360ms or something. Starting it with the wm keybinds is as snappy as opening a new Firefox tab. foot and st felt as fast when I was using them.

Foot is instant. Ghostty takes ages. I don’t know why there’s such a difference, but I can’t use anything slower than Foot now without getting annoyed.

Yep, I want really fast startup too. Of the two I use:

xfce4-terminal starts utterly instantly without single instance feature.

Kitty has the single instance feature and starts instantly with it.

Speed itself may not be very important, but it is a very interesting challenge in itself - to prove to yourself that you can surpass the state of the art!

IME, usually you care more about latency than throughput for normal interactions, and there is a noticeable difference between the slowest ones, and the fastest ones, but I've tried a lot of terminal emulators, and any of the ones that put some effort into performance are plenty fast enough.

However, there is one case when throughput matters: when an application has a lot of output. But then the problem isn't the speed that it displays the text, it's going by too fast to read anyway, the problem is that the application can be slowed down by blocking on writing to stdout when the buffer is full. And honestly, the best approach in that case is probably not to actually render all the text, but send most of the output straight to the scrollback buffer, and only render some of the frames.

Terminal.app is amongst the best, if these old danluu benchmarks still hold https://danluu.com/term-latency/

Right? I have always just used whichever terminal came with the Linux desktop I was using at the time. If anything, the terminal is already the smallest and fastest gui app I have open.

I ask this question often in the comments when a new "blazingly fast" terminal is announced and after years of doing so, have yet to read an actually practical answer that applies to modern systems.

My guess is that some people just enjoy the process of optimizing well-understiod low-stakes graphical stuff.

I would still use xterm, don't really get the craze out optimising tty emulators.

Now graphical nicely powered REPL environments is another matter.

I keep going back to xfce-terminal after trying anything else. Ridiculously small footprint and never drew attention to itself.

the new Windows Terminal had horrendous performance when it first came out. in the aftermath of the drama surrounding that, was when I first started seeing a lot of terminal emulator projects bragging about their throughput.

Regardless of all the twitter and Github drama, it was fast enough for me, and I don't get what is the interest running HLSL shaders, pets extensions or rainbow colours on the terminal.

Reply on news.ycombinator.com