Don't forget WezTerm, which is imo the best of the recent crop of GPU-accelerated terminal emulators implemented in Rust (with built-in multiplexing!):

https://wezfurlong.org/wezterm/

Having now tried Warp, I think it's fine. I doubt performance will be a problem. What concerns me more is that it's not open-source.

Good question! We did an initial benchmark of scrolling back in July against Terminal, iTerm, Hyper, Kitty, and Alacritty, if you’re interested: https://www.warp.dev/blog/how-warp-works.

We started by forking Alacritty's model and parser and because we have a similar architecture (Rust-based, rendered on the GPU) we should generally be at, or near, the performance of Alacritty.

I just ran a quick test using Casey Muratori's termbench (https://github.com/cmuratori/termbench) you are an order of magnitude slower than Alacritty, and also significantly slower than iTerm. Warp also locks up pretty severely and only shows a new frame once every few seconds during most of the run.

Alacritty

CPU: Intel(R) Core(TM) i9-9880H CPU @ 2.30GHz

VT support: no

ManyLine: 1.5670s (0.0399gb/s)

LongLine: 1.1261s (0.0555gb/s)

FGPerChar: 0.3293s (0.0551gb/s)

FGBGPerChar: 0.6598s (0.0534gb/s)

TermMarkV2 Small: 3.6822s (0.0484gb/s)

iTerm

CPU: Intel(R) Core(TM) i9-9880H CPU @ 2.30GHz

VT support: no

ManyLine: 13.2968s (0.0047gb/s)

LongLine: 3.6535s (0.0171gb/s)

FGPerChar: 1.8944s (0.0096gb/s)

FGBGPerChar: 2.8304s (0.0125gb/s)

TermMarkV2 Small: 21.6750s (0.0082gb/s)

Warp

CPU: Intel(R) Core(TM) i9-9880H CPU @ 2.30GHz

VT support: no

ManyLine: 9.6199s (0.0065gb/s)

LongLine: 8.3727s (0.0075gb/s)

FGPerChar: 8.1124s (0.0022gb/s)

FGBGPerChar: 6.0873s (0.0058gb/s)

TermMarkV2 Small: 32.1924s (0.0055gb/s)

Yeah, this is a known issue, unfortunately--but it's definitely something we want to fix as we improve Warp. See more information here where we chat with Casey about it: https://twitter.com/zachlloydtweets/status/14175482714432348...

> we should generally be at, or near, the performance of Alacritty

> evidence that it’s not

> Yeah, this is a known issue

I don’t want to be critical, but which is it? If you know you are not anywhere near the performance, why say you are?

> If you know you are not anywhere near the performance, why say you are?

(in a voice like Jon Lovitz as Master Thespian) Marketing!

Hey - that's a good point. The thing about terminal benchmarks is that there are many of them, each focusing on a different aspect and producing different results. There's one by alacritty team[1] that we used in our initial tests[2], there's another ones mentioned in the comments above etc. When using vtbench, Warp performed much better than iterm, for example.

Ideally we'd ace all of them, but we're not there yet. Anecdotally, many of our users mention speed/performance improvements over other terminal apps a lot in our Discord!

[1] https://github.com/alacritty/vtebench [2] https://www.warp.dev/blog/how-warp-works

I don’t see the contradiction. They should be, but they aren’t.

I've tried one very basic terminal rendering benchmark I had at hand [1] and on my MacBook Pro it was 17x faster than iterm and 3x faster than wezterm which is my daily driver.

https://github.com/wez/wezterm/issues/192

So it's not all that bad ;)

thanks for posting this—no idea why every new terminal released today doesn't test against termbench and/or take a look at refterm these days, that's the first thing I would do.

What do performance problems in a terminal even look like?

I feel like a crazy person in this thread because I’ve literally never had the thought: “I could be so much more productive but this damn terminal is slowing me down”.

Imagine you're using a terminal based text editor full-screen with say 364 columns and 77 rows. You've got it nicely split into three vertical windows for code, with a tree display a fort window on the left-hand side. One of these three code windows is split horizontally and is tailing a log file, and you're quickly paging through code on another.

This is a lot of terminal I/O, and you want this scrolling to be fast, smooth, and to not flash or blink awkwardly.

I do this because I'm running my editor on a remote machine over SSH, which has a ton of cores, memory, and fast disk. Just firing up the LSP server on this giant monorepo causes the fans on my laptop to spin like crazy and takes forever to initialize. Blazing fast on this remote host.

It matters if you regularly dump huge amounts of text to the terminal. In other words it rarely matters to most people. In fact, if it did, more people would realise that the terminals they use are often quite slow compared to ones like e.g rxvt.

Most terminals don't even implement most well understood "hacks" to keep up with the apps they're running (e.g. "render" to a text buffer and render the text buffer to the screen separately and decoupled (multiplex or on separate threads)), because people rarely are affected enough to care.

The terminal is a surprisingly performance intensive application. When we built an initial prototype in electron, it was struggling to render full screens of text output on large screens. We want to support 144 fps on 4K monitors.

Additionally, Warp has GUI elements like blocks and context menus. We talk about performance because when we discuss our features, people automatically assume it's going to be sluggish.

Hmm, I’ve definitely had commands run in the terminal that were speed limited by how fast the terminal could output the results.

Kitty is awesome, but no windows if you're into that. Alacritty awesome as well, but minimalistic and rust which I have no idea why it matters in OPs post or in general.

I appreciate memory safety in applications that handle and interpret data controlled by third-parties. Kitty and Alacritty stand apart as written in memory safe languages, unlike the vast majority of terminal emulators which are written in C/C++. Doesn't mean their bug-free, but they're less likely to have trivial RCE vulnerabilities.

Kitty is written in C, afaik.

It's a mix of Python and C