6 ms·

> Not to dismiss concerns about terminal performance, but if you need a terminal to keep up at ten gigabytes per second of data, I question your goals* . I don

> Not to dismiss concerns about terminal performance, but if you need a terminal to keep up at ten gigabytes per second of data, I question your goals* . I don't want OOM killer to murder everything just because I accidentally catted a 1 GB file to stdout rather than another file. Or accidentally catted the .iso rather than the .iso.asc. Nor do I want to wait 5 minutes for the terminal to render it all. Sure, accidents don't happen every day, but it's a massive inconvenience if it does. It was enough to make me abandon all feature-rich VTE based terminals in favour of rvxt.

zbentley 9y ago
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.

6 ms·

> Not to dismiss concerns about terminal performance, but if you need a terminal to keep up at ten gigabytes per second of data, I question your goals* . I don

by creshal 9y ago

zbentley 9y ago
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.