[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.