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)

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 ...

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.

All valid points, but (anecdotally) over the past several years of work, this holds true.

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.

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

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.