4 ms·

I strongly don’t think that throughput is what terminal emulators should optimise for: basically no one cares about how quickly you can get a load of text you w

I strongly don’t think that throughput is what terminal emulators should optimise for: basically no one cares about how quickly you can get a load of text you will ignore. Instead, kill the command and modify it to reduce output. I think the right thing to optimise for is input latency.

coldtea 6y ago
>I strongly don’t think that throughput is what terminal emulators should optimise for: basically no one cares about how quickly you can get a load of text you will ignore. Instead They would care if they knew it would also block their program doing the output...
- dan-robertson 6y ago
  Ssh also has this problem to a greater extent and is very commonly used
  - scaladev 6y ago
    One can enable compression by default for all ssh connections by adding Compression yes to ~/.ssh/config It can pipe many megabytes of text output per second on relatively slow channels (`ssh -vv` prints the total data transfer when you close the connection), as long as it's not encrypted or unable to be compressed for some other reason (which is pretty rare for text output). Scrolling very large files in vim becomes much faster, for example.
  - fullstop 6y ago
    This might be useful for some: https://mosh.org/ https://mosh.org/ It is great for unstable / slow links and pressing ctrl+c works immediately which is nice.
iainmerrick 6y ago
I strongly disagree! It shouldn’t be that hard to make this fast, and it’s a very common source of slowdown in builds, so why not just make it fast? As to why you shouldn’t just silence all that noisy spam output, you never know when you might need it to diagnose a weird build error. Sure, it would be great if the build system always produced nice concise output with exactly the error messages you need, but that’s not always realistic. A big bunch of spam that you can dig into if you need to is almost as good -- as long as it doesn’t slow you down. Edit to add: I guess another approach is to redirect spammy output to a file instead of the terminal. But then I have to know in advance which commands are going to be noisy, and it introduces another workflow (maybe the error message you need is right at the end of the output, but now it’s tucked away in a file instead of right there in your terminal). Just make the terminal fast at handling large output. No reason that should make it harder to have good input latency too.
- dan-robertson 6y ago
  One thing to consider is that ssh is much more likely to be throttling than the terminal emulator, so having a really fast terminal emulator won’t really fix problems with programs that output too much. I’m also not saying that throughput should be totally ignored, just that it shouldn’t be the metric used to benchmark and optimise ones terminal emulator.
  - deleted 6y ago
    [deleted]
joosters 6y ago
Input latency is the problem for many terminals when a command accidentally generates megabytes of output text - the console locks up and won't respond to input until it has rendered and scrolled through every single line of output. Surprisingly few terminals, when suddenly faced with a million new lines of text, decide "hey, let's just draw the last screen of output, I don't need to draw each and every line and then move the existing text upwards by a row"
- tux3 6y ago
  There's a good reason terminals can't just skip ahead, even if we ignore ANSI/vt100/etc escape sequences, even "plain text" is not so plain. Some applications output a few lines, then many MBs of "\rcurrent progress: xx.xxx%" that constantly overwrites itself. Rendering is just not linear.
  - swiley 6y ago
    tmux will skip drawing text if it gets enough of it, it still maintains state but it waits to render it.
howaboutnope 6y ago
Maybe not something to optimize for, but still something to optimize when you can do it without sacrificing speed or functionality in other areas.

coldtea 6y ago

>I strongly don’t think that throughput is what terminal emulators should optimise for: basically no one cares about how quickly you can get a load of text you will ignore. Instead They would care if they knew it would also block their program doing the output...

dan-robertson 6y ago
Ssh also has this problem to a greater extent and is very commonly used
- scaladev 6y ago
  One can enable compression by default for all ssh connections by adding Compression yes to ~/.ssh/config It can pipe many megabytes of text output per second on relatively slow channels (`ssh -vv` prints the total data transfer when you close the connection), as long as it's not encrypted or unable to be compressed for some other reason (which is pretty rare for text output). Scrolling very large files in vim becomes much faster, for example.
- fullstop 6y ago
  This might be useful for some: https://mosh.org/ https://mosh.org/ It is great for unstable / slow links and pressing ctrl+c works immediately which is nice.

iainmerrick 6y ago

I strongly disagree! It shouldn’t be that hard to make this fast, and it’s a very common source of slowdown in builds, so why not just make it fast? As to why you shouldn’t just silence all that noisy spam output, you never know when you might need it to diagnose a weird build error. Sure, it would be great if the build system always produced nice concise output with exactly the error messages you need, but that’s not always realistic. A big bunch of spam that you can dig into if you need to is almost as good -- as long as it doesn’t slow you down. Edit to add: I guess another approach is to redirect spammy output to a file instead of the terminal. But then I have to know in advance which commands are going to be noisy, and it introduces another workflow (maybe the error message you need is right at the end of the output, but now it’s tucked away in a file instead of right there in your terminal). Just make the terminal fast at handling large output. No reason that should make it harder to have good input latency too.

dan-robertson 6y ago
One thing to consider is that ssh is much more likely to be throttling than the terminal emulator, so having a really fast terminal emulator won’t really fix problems with programs that output too much. I’m also not saying that throughput should be totally ignored, just that it shouldn’t be the metric used to benchmark and optimise ones terminal emulator.
- deleted 6y ago
  [deleted]

joosters 6y ago

Input latency is the problem for many terminals when a command accidentally generates megabytes of output text - the console locks up and won't respond to input until it has rendered and scrolled through every single line of output. Surprisingly few terminals, when suddenly faced with a million new lines of text, decide "hey, let's just draw the last screen of output, I don't need to draw each and every line and then move the existing text upwards by a row"

tux3 6y ago
There's a good reason terminals can't just skip ahead, even if we ignore ANSI/vt100/etc escape sequences, even "plain text" is not so plain. Some applications output a few lines, then many MBs of "\rcurrent progress: xx.xxx%" that constantly overwrites itself. Rendering is just not linear.
- swiley 6y ago
  tmux will skip drawing text if it gets enough of it, it still maintains state but it waits to render it.

howaboutnope 6y ago

Maybe not something to optimize for, but still something to optimize when you can do it without sacrificing speed or functionality in other areas.