3

I am running a timed find command as normal user.

What I know is that redirection is to prevent stdout/stderr messages on the terminal. If that's the case, why do different redirections methods take different amounts of time? Is it somehow related to the write speed on the tty or is there any other reason behind it? Could someone point me in right direction in understanding this?

$ id
uid=1000(user1) gid=1000(user1) groups=1000(user1),1001(user2)

$time find /
<truncated output>
real    0m13.902s
user    0m0.197s
sys 0m0.448s

$ time find /  >/dev/null  
<truncated output>
real    0m0.298s
user    0m0.068s
sys 0m0.206s

$time find /  2> /dev/null 
<truncated output>
real    0m13.279s
user    0m0.181s
sys 0m0.405s

$ time find /  > /dev/null 2>&1
real    0m0.306s
user    0m0.109s
sys 0m0.174s
1
  • 1
    Note how the redirection type doesn't affect the user and system times nearly as much as the real time. The slow-down clearly comes from something outside of find that stalls its execution, i. e. blocking system calls that put its thread into the "waiting" scheduler state. Commented May 31, 2017 at 8:25

2 Answers 2

5

When your process (find) needs to actually write out the output, that obviously takes a lot longer than when you tell it to discard said output.

  • When you use find /, both the stdout and stderr are sent to your terminal, and it has to write out both of them (i.e., the actual results and all the permission errors and whatnot)

  • When you use time find / >/dev/null you are dropping the standard output of the command, but still printing out all the errors (if you have any). Judging by your results, you have lots of legitimate results and very few errors.

  • When you use time find / 2> /dev/null, the standard output of the command is still being sent to your terminal, but now you're simply dropping the stderr. If you were finding through a filesystem that you did not have permission to read, this would actually be pretty fast.

  • When you use time find / > /dev/null 2>&1, you are dropping the standard output, and then sending standard error to where standard output is being sent,... i.e., you are dropping both. This will not output anything, and thus will be the fastest of all commands.

3
  • 2
    TL;DR:  Yes, writing text to the tty takes time. Commented May 31, 2017 at 6:45
  • It's often limited by the speed of whatever receives the text. Compiling a kernel on a vt220 with the output going to the terminal took much longer than when saving the output to a file.
    – Kusalananda
    Commented May 31, 2017 at 8:47
  • 3
    find itself does exactly the same amount of work in all cases. The extra work that slows everything down is done by your terminal emulator, which has to scan every character for VT100 escapes and then render the text into a pixel buffer, and the X server, which is responsible for painting the pixel buffer on the screen. find does take longer in wall-clock terms, but only because it keeps filling up the tty output queue and getting blocked.
    – zwol
    Commented May 31, 2017 at 12:14
3

What I know is that redirection is to prevent stdout/stderr messages on the terminal.

Well, no: you could also redirect to a file:

find / > ~/all-the-files

Is it somehow related to the write speed on the tty?

In a word, yes.

Regardless of what kind of a terminal you're using (virtual console in Linux, a local xterm, something over an SSH connection), the actual terminal emulator has to draw everything printed on the terminal, even though in this case it's going to scroll out soon. (A connection over mosh might be an exception here.)

Over a network connection, there's also the transfer delay to consider, some data may be buffered, if there's lots of it, not all. If you redirect something to /dev/null, it's not saved anywhere, and not drawn either. Redirecting to a file will also be fast with moderate amounts of data, since the OS probably caches the writes in memory, and only actually writes to disk lazily afterwards. With a large amount of data, writing to disk might also become a bottleneck. (or, if you managed to have the process write the output in synchronous I/O mode)

For programs doing lots of output, just the process of formatting the output (printf() within the process) and calling out to the OS to write it would take time even if the data was redirected to /dev/null. In a case like that, it might be even faster if you could persuade the program to inhibit output completely. This probably isn't the case with find, I'd assume it would be bound be the I/O speed or the system call overhead.

Do also note that if you run find in the same directory tree repeatedly, the first time is likely to be slower than the others, since the first time may require reading from disk, while after that, much of the data will be cached by the OS.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .