¿Por qué existe una diferencia en la duración de la ejecución del comando con diferentes métodos de redirección?

Question

Estoy ejecutando un findcomando cronometrado como usuario normal.

Lo que sé es que la redirección es para evitar mensajes stdout/stderr en el terminal. Si ese es el caso, ¿por qué los diferentes métodos de redireccionamiento toman diferentes cantidades de tiempo? ¿Está relacionado de alguna manera con la velocidad de escritura en el tty o hay alguna otra razón detrás de esto? ¿Alguien podría indicarme la dirección correcta para entender esto?

$ 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

Answer 1

Cuando su proceso ( find) necesita realmente escribir la salida, eso obviamente lleva mucho más tiempo que cuando le dice que descarte dicha salida.

• Cuando usas find /, tanto stdout como stderr se envían a tu terminal, y tiene que escribir ambos (es decir, los resultados reales y todos los errores de permisos y demás)

• Cuando lo usa, time find / >/dev/nullelimina la salida estándar del comando, pero aún imprime todos los errores (si tiene alguno). A juzgar por sus resultados, tiene muchos resultados legítimos y muy pocos errores.

• Cuando usas time find / 2> /dev/null, la salida estándar del comando todavía se envía a tu terminal, pero ahora simplemente estás eliminando el stderr. Si encontrara a través de un sistema de archivos que no tiene permiso para leer, esto sería bastante rápido.

• Cuando usa time find / > /dev/null 2>&1, descarta la salida estándar y luego envía un error estándar al lugar donde se envía la salida estándar,... es decir, descarta ambas. Esto no generará nada y, por lo tanto, será el más rápido de todos los comandos.

Answer 2

Lo que sé es que la redirección es para evitar mensajes stdout/stderr en el terminal.

Bueno, no: también puedes redirigir a un archivo:

find / > ~/all-the-files

¿Está relacionado de alguna manera con la velocidad de escritura en el tty?

En una palabra, sí.

Independientemente del tipo de terminal que esté utilizando (consola virtual en Linux, un xterm local, algo a través de una conexión SSH), el emulador de terminal real tiene que dibujar todo lo impreso en el terminal, aunque en este caso se desplazará pronto. (Una conexión terminada moshpodría ser una excepción aquí).

A través de una conexión de red, también hay que considerar el retraso en la transferencia, algunos datos pueden almacenarse en el búfer, si hay muchos, no todos. Si redirige algo a /dev/null, no se guarda en ningún lugar ni se dibuja. Redirigir a un archivo también será rápido con cantidades moderadas de datos, ya que el sistema operativo probablemente almacene en caché las escrituras en la memoria y luego solo escriba en el disco de manera perezosa. Con una gran cantidad de datos, escribir en el disco también puede convertirse en un cuello de botella. (o, si logró que el proceso escribiera la salida en modo de E/S síncrono)

Para los programas que generan muchos resultados, solo el proceso de formatear el resultado ( printf()dentro del proceso) y llamar al sistema operativo para que lo escriba llevaría tiempo incluso si los datos se redirigieran a /dev/null. En un caso como ese, podría ser incluso más rápido si pudiera persuadir al programa para que inhibiera la salida por completo. Probablemente este no sea el caso con find, supongo que sería la velocidad de E/S o la sobrecarga de la llamada al sistema.

También tenga en cuenta que si ejecuta findel mismo árbol de directorios repetidamente, es probable que la primera vez sea más lenta que las otras, ya que la primera vez puede requerir lectura desde el disco, mientras que después de eso, el sistema operativo almacenará en caché gran parte de los datos. .