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.