6 ms·

I can't answer specifically for `apt`, but many commands take significantly longer if you let them display to stdout versus piping their output to a file or `/d

by clebio 11y ago

I can't answer specifically for `apt`, but many commands take significantly longer if you let them display to stdout versus piping their output to a file or `/dev/null`. cf.: $ time ls -R /usr real 0m7.570s user 0m0.104s sys 0m2.286s $ time ls -R /usr > /dev/null real 0m0.193s user 0m0.036s sys 0m0.154s (edit: when will I grok HN markup?? cough support markdown cough)

jasonjayr 11y ago
Did you run those two commands in sequence? Did you account for disk-cache effects? Try running it 4 times, alternating the versions and see what your last 2 times are ...
- clebio 11y ago
  All valid points, but (anecdotally) over the past several years of work, this holds true.
- vacri 11y ago
  You can actually show different speeds in different terminals - the speed of terminal rendering affects the duration of the test. In the tests below, I have no custom terminal prompts or similar (no git status lines etc) - they're all distribution defaults running bash. # all the below run in the same MATE desktop # lxterm (from lxde - is easiest on my eye) $ time ls -R /usr real 0m19.974s user 0m0.860s sys 0m0.832s # gnome terminal $ time ls -R /usr real 0m19.902s user 0m0.800s sys 0m0.776s # xterm (yes, it really is 10x the speed) $ time ls -R /usr real 0m1.872s user 0m0.856s sys 0m0.800s # rerun in the first terminal, and the time hasn't changed - still 19s # now in lxterm redirecting to null # (and xterm gives similar results here) $ time ls -R /usr > /dev/null real 0m0.418s user 0m0.256s sys 0m0.156s All that prettification and rendering takes time; if you want raw speed, use xterm... or pipe output to /dev/null. Interestingly, 'time' on gterm and lxterm had tabs between the above field:value pairs (I had to reformat to show them nicely), but xterm used spaces. I don't know enough about the terminal underpinnings to guess as to why.
josho 11y ago
I've always assumed something like the above is slow due to the terminal blocking the program to perform updates to the display. Whereas a status indicator isn't exactly pushing much data to the terminal. So, It shouldn't impact run time.
- clebio 11y ago
  Yes, that's a reasonable assumption. I am by no means a terminal guru, but my understanding is that, for something like a progress bar or spinner (anything that is updated in-place in the terminal), the entire "screen" is being redrawn on update.
- clebio 11y ago
  I also suspect (though have not verified) that any output to terminal is quite a bit slower than the raw operation -- that sort of difference that we should all know, as programmers. http://norvig.com/21-days.html#answers http://norvig.com/21-days.html#answers

by clebio 11y ago

jasonjayr 11y ago

Did you run those two commands in sequence? Did you account for disk-cache effects? Try running it 4 times, alternating the versions and see what your last 2 times are ...

clebio 11y ago
All valid points, but (anecdotally) over the past several years of work, this holds true.
vacri 11y ago
You can actually show different speeds in different terminals - the speed of terminal rendering affects the duration of the test. In the tests below, I have no custom terminal prompts or similar (no git status lines etc) - they're all distribution defaults running bash. # all the below run in the same MATE desktop # lxterm (from lxde - is easiest on my eye) $ time ls -R /usr real 0m19.974s user 0m0.860s sys 0m0.832s # gnome terminal $ time ls -R /usr real 0m19.902s user 0m0.800s sys 0m0.776s # xterm (yes, it really is 10x the speed) $ time ls -R /usr real 0m1.872s user 0m0.856s sys 0m0.800s # rerun in the first terminal, and the time hasn't changed - still 19s # now in lxterm redirecting to null # (and xterm gives similar results here) $ time ls -R /usr > /dev/null real 0m0.418s user 0m0.256s sys 0m0.156s All that prettification and rendering takes time; if you want raw speed, use xterm... or pipe output to /dev/null. Interestingly, 'time' on gterm and lxterm had tabs between the above field:value pairs (I had to reformat to show them nicely), but xterm used spaces. I don't know enough about the terminal underpinnings to guess as to why.

josho 11y ago

I've always assumed something like the above is slow due to the terminal blocking the program to perform updates to the display. Whereas a status indicator isn't exactly pushing much data to the terminal. So, It shouldn't impact run time.

clebio 11y ago
Yes, that's a reasonable assumption. I am by no means a terminal guru, but my understanding is that, for something like a progress bar or spinner (anything that is updated in-place in the terminal), the entire "screen" is being redrawn on update.
clebio 11y ago
I also suspect (though have not verified) that any output to terminal is quite a bit slower than the raw operation -- that sort of difference that we should all know, as programmers. http://norvig.com/21-days.html#answers http://norvig.com/21-days.html#answers