¿El tee ralentiza las tuberías?

Me pregunto si el tee ralentiza las tuberías. Escribir datos en el disco es más lento que conectarlos, después de todo.

¿Espera un momento con el envío de datos a la siguiente tubería hasta que se haya escrito en el disco? (De lo contrario, supongo que tee tiene que poner en queue los datos que se enviaron, pero no se escribieron en el disco, lo cual me parece improbable).

$ program1 input.txt | tee intermediate-file.txt | program2 ... 

Sí, ralentiza las cosas. Y básicamente tiene una queue de datos no escritos, aunque en realidad lo mantiene el kernel; todos los progtwigs tienen eso, a less que explícitamente soliciten lo contrario.

Por ejemplo, aquí hay un conducto trivial que usa pv , que es bueno porque muestra la velocidad de transferencia:

 $ pv -s 50g -S -pteba /dev/zero | cat > /dev/null 50GiB 0:00:09 [ 5.4GiB/s] [===============================================>] 100% 

Ahora, agreguemos una tee , ni siquiera escriba una copy extra, solo reenviándola:

 $ pv -s 50g -S -pteba /dev/zero | tee | cat > /dev/null 50GiB 0:00:20 [2.44GiB/s] [===============================================>] 100% 

Entonces, eso es bastante más lento, ¡y ni siquiera estaba haciendo nada! Esa es la sobrecarga de tee que copy internamente STDIN a STDOUT. (Curiosamente, agregar un segundo pv queda en 5.19GiB / s, por lo que pv es sustancialmente más rápido que el tee . pv usa el splice(2) , el tee probablemente no).

De todos modos, veamos qué sucede si le digo a tee que escriba en un file en el disco. Comienza bastante rápido (~ 800MiB / s) pero a medida que avanza, se ralentiza, en última instancia hasta ~ 100MiB / s, que es básicamente el 100% del ancho de banda de escritura del disco. (El inicio rápido se debe a que el núcleo almacena en caching la escritura del disco, y la ralentización a la velocidad de escritura del disco es que el kernel se niega a permitir que el caching crezca infinitamente).

¿Importa?

Lo anterior es el peor de los casos. Lo anterior usa una tubería para arrojar datos lo más rápido posible. El único uso en el mundo real en el que puedo pensar es como extraer los datos de YUV sin procesar a / desde ffmpeg .

Cuando envía datos a velocidades más lentas (porque los está procesando, etc.) va a tener un efecto mucho less significativo.