5 ms·

> Historically, the Windows Command Prompt and the built-in Terminal.app on macOS were very slow at handling tons of output. A very old trick I remember on Win

by chungy 6y ago

> Historically, the Windows Command Prompt and the built-in Terminal.app on macOS were very slow at handling tons of output. A very old trick I remember on Windows, is to minimize command prompts if a lot of output was expected and would otherwise slow down the process. I don't know if it turned write operations into a no-op, or bypassed some slow GDI functions, but it had an extremely noticeable difference in performance.

lifthrasiir 6y ago
IIRC the font rendering in Windows was surprisingly slow and even somewhat unsafe. In one case lots of different webfonts displayed in the MSIE rendered the whole text rendering stack broken, with all text across the entire system disappeared. I wouldn't be surprised if this is a root cause of slow command prompts.
- patates 6y ago
  Well that explains the crazy slow performance on an old windows forms app I had written back when I was a junior developer. I'll try to see if I can reach anyone from my first employer and make them disable the debug output. Would be an interesting contribution, considering that I left more than 10 years ago :)
  - ygra 6y ago
    Old old Windows Forms had its own text rendering (and still has), but most controls now have a second code path that uses the system's text renderer, which got updated with better shaping, more scripts, etc., while GDI+ basically never got any updates. You can see that when there's a call to SetCompatibleTextRendering(false) in the code somewhere; then it's using GDI instead of GDI+.
- gmueckl 6y ago
  This sounds a lot like GDI resource exhaustion. It looks like the limits on handle IDs and the GDI heap size are still in place even in Windows 10.
dan-robertson 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, 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.
magicalhippo 6y ago
> bypassed some slow GDI functions I think it is mainly just the scroll operation. You can visually see the process speeding up as you reduce the height of the console window. Typically I reduce it to a couple of lines, then it goes several times faster yet I can keep an eye on it.
hinkley 6y ago
As I recall, command line scrolling output was also faster if you minimized the window. You just needed an alert of some sort when the thing was done, like a bell or audio file. There was a period of time where I earned brownie points by flushing all of the defunct debugging output from old bugs that nobody removed, typically for a 2x improvement in app performance. All because of screen scroll bottlenecks.

by chungy 6y ago

lifthrasiir 6y ago

IIRC the font rendering in Windows was surprisingly slow and even somewhat unsafe. In one case lots of different webfonts displayed in the MSIE rendered the whole text rendering stack broken, with all text across the entire system disappeared. I wouldn't be surprised if this is a root cause of slow command prompts.

patates 6y ago
Well that explains the crazy slow performance on an old windows forms app I had written back when I was a junior developer. I'll try to see if I can reach anyone from my first employer and make them disable the debug output. Would be an interesting contribution, considering that I left more than 10 years ago :)
- ygra 6y ago
  Old old Windows Forms had its own text rendering (and still has), but most controls now have a second code path that uses the system's text renderer, which got updated with better shaping, more scripts, etc., while GDI+ basically never got any updates. You can see that when there's a call to SetCompatibleTextRendering(false) in the code somewhere; then it's using GDI instead of GDI+.
gmueckl 6y ago
This sounds a lot like GDI resource exhaustion. It looks like the limits on handle IDs and the GDI heap size are still in place even in Windows 10.

dan-robertson 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, 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.

magicalhippo 6y ago

> bypassed some slow GDI functions I think it is mainly just the scroll operation. You can visually see the process speeding up as you reduce the height of the console window. Typically I reduce it to a couple of lines, then it goes several times faster yet I can keep an eye on it.

hinkley 6y ago

As I recall, command line scrolling output was also faster if you minimized the window. You just needed an alert of some sort when the thing was done, like a bell or audio file. There was a period of time where I earned brownie points by flushing all of the defunct debugging output from old bugs that nobody removed, typically for a 2x improvement in app performance. All because of screen scroll bottlenecks.