4 ms·
cool project, but my question is why? rxvt is plenty fast for general purposes. if your bottleneck is the terminal emulator then you're doing something wrong. c
by mistaken 10y ago
cool project, but my question is why? rxvt is plenty fast for general purposes. if your bottleneck is the terminal emulator then you're doing something wrong. can you really read at ~10mbps?
- db48x 10y agoNo, of course you can't read all of the text at 10Mbps. The problem is that when you start some task which has a lot of spew, just having all of that text scrolling past can slow everything down to the point where the task actually takes longer! Even a few percentage points of slowdown can add up to minutes just sitting there twiddling your thumb. Just a few weeks ago I accidentally ran a command on a remote machine that generated so much spew in the few seconds it ran before I hit control-c that it took 5 minutes to scroll through before I could do anything else. But yes, you probably want to avoid that much text spew even if your terminal is super fast.
- mistaken 10y agoyep: cmd &> /dev/null maybe? :) or ctlr-z; disown; exit... at any rate we're optimizing for edge cases
- db48x 10y ago&>- would be faster, as long as we're at it. But, the point is that sometimes it's a huge cost, and the rest of the time it's a tiny continuous slowdown.
- JdeBP 10y agoYou think that your bottleneck is the terminal emulator, but you are wrong. As the mosh people pointed out a few years ago, the output from the remote machine has to scroll for 5 minutes because it is all backed up in the SSH connection between your machine and the remote one. Your bottleneck isn't in the terminal emulator at all, and changing terminal emulators to whizzy new ones will not make any difference to it.