Upterm – A terminal emulator and interactive shell based on Electron

Re:Upterm – A terminal emulator and interactive shell based ... by zbentley on Thursday September 21, 2017 @09:24AM (#15303057)

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* . How can you seek in that much data? Will you page-up or scroll for hours to find what you need? Past 1GB in the buffer, even iTerm2s search functionality lags out painfully, but . . . so does grep, on a file that big.

There are other aspects of terminal performance that are very important, and you may have meant to point towards those, but as it is this comment just reads as bikeshedding. "Performance is (a|the most important) feature" refers to performance in areas that matter.

* And yes, I know that yes(1) can be used for performance/stress testing of systems by outputting endlessly. Doing that to a human-consumed TTY seems like an example of spacebar heating: https://xkcd.com/1172/

[ Parent | on HN ]

Re:Upterm – A terminal emulator and interactive shell based ... by creshal on Thursday September 21, 2017 @11:13AM (#15304234)

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

[ Parent | on HN ]

Re:Upterm – A terminal emulator and interactive shell based ... by zbentley on Thursday September 21, 2017 @11:25AM (#15304375)

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.

[ Parent | on HN ]

Re:Upterm – A terminal emulator and interactive shell based ... by 013a on Thursday September 21, 2017 @10:13AM (#15303592)

Usually performance in GNU yes is a canary for other bad performance. Its more like saying "if you can handle yes, you can handle anything." I've legitimately crashed hyper term (another electron-base term) when dumping other large amounts of data, like in large log files.

[ Parent | on HN ]