https://danluu.com/term-latency/ (Previous discussion: https://news.ycombinator.com/item?id=14798211)
Recently there was this terminal performance test https://danluu.com/term-latency/
The author says that the most important things are typing delay and how quickly you can Ctrl+C a command, not how much text it prints per second. Upterm is good at both.
Considering I dropped those because I consider them slow and bloated, good luck with this Electron monstrosity.
You can have my RXVT when you pry it from my cold, dead hands.
I dropped those because they're magnitudes slower than urxvt. You managed to make a terminal emulator that's even worse?
Not every tool fits everyone’s needs. Some tools might only be useful to a few people.
No need to be rude about it.
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/
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.
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.