Those are good points about stability and memory usage, but I'm not sure what they have to do with performance. I'd be surprised (well, not that surprised, but

Those are good points about stability and memory usage, but I'm not sure what they have to do with performance. I'd be surprised (well, not that surprised, but a little surprised and disappointed) if terminal programs were actively storing all of data they read out of pipes into memory before displaying it, rather than a read-some/print-some informally buffered approach. Similarly, I don't think holding the data in the "displayed output" state is going to OOM your terminal out of the box: I get the impression that most terminal programs have a fairly conservative history-line-buffer size in order to avoid this family of problem. This isn't the same as crashing/hanging your terminal's command-output parser (depressingly easy in Upterm) due to volume; when that happens, the process writing tons of data (cat my_huge_file.dat) will fill up its STDOUT pipe and usually block until the situation is resolved. I think that stability-in-the-face-of-large-output behavior is what you're referring to, rather than OOM killing, in which case I agree wholeheartedly that the behavior of terminal systems (and remote shell systems, etc.) is distressingly bad in the face of large-data influx situations.