Oui, cela ralentit les choses. Et il a en fait une file d'attente de données non écrites, bien que celle-ci soit en fait gérée par le noyau - tous les programmes en ont, à moins qu'ils ne demandent explicitement le contraire.
Par exemple, voici un tube trivial utilisant pv, ce qui est bien car il affiche le taux de transfert:
$ pv -s 50g -S -pteba /dev/zero | cat > /dev/null
50GiB 0:00:09 [ 5.4GiB/s] [===============================================>] 100%
Maintenant, ajoutons un teededans, pas même d'écrire une copie supplémentaire, juste de le faire suivre:
$ pv -s 50g -S -pteba /dev/zero | tee | cat > /dev/null
50GiB 0:00:20 [2.44GiB/s] [===============================================>] 100%
Donc, c'est un peu plus lent, et ça ne faisait même rien! C'est le surcoût de la copie interne de STDIN vers STDOUT. (Fait intéressant, l'ajout d'une seconde pvreste à 5,19 Go / s, ce qui pvest donc beaucoup plus rapide que les utilisations tee. , Probablement pas.)pvsplice(2)tee
Quoi qu'il en soit, voyons ce qui se passe si je dis teed'écrire dans un fichier sur le disque. Il démarre assez rapidement (~ 800 Mo / s), mais au fur et à mesure, il continue de ralentir - finalement jusqu'à ~ 100 Mo / s, ce qui représente essentiellement 100% de la bande passante d'écriture du disque. (Le démarrage rapide est dû au fait que le noyau met en cache l'écriture sur le disque et le ralentissement de la vitesse d'écriture sur le disque est le refus du noyau de laisser le cache croître à l'infini.)
Est-ce que ça importe?
Ce qui précède est le pire des cas. Ce qui précède utilise un tuyau pour cracher des données aussi rapidement que possible. La seule utilisation dans le monde réel à laquelle je peux penser comme celle-ci consiste à canaliser des données YUV brutes vers / depuis ffmpeg.
Lorsque vous envoyez des données à un rythme plus lent (parce que vous les traitez, etc.), cela aura un effet beaucoup moins important.