Да, это замедляет ход событий. И у него в основном есть очередь неписанных данных, хотя на самом деле они поддерживаются ядром - так есть во всех программах, если они явно не требуют другого.
Например, вот тривиальное использование канала pv, что приятно, поскольку отображает скорость передачи:
$ pv -s 50g -S -pteba /dev/zero | cat > /dev/null
50GiB 0:00:09 [ 5.4GiB/s] [===============================================>] 100%
Теперь давайте добавим teeтуда, даже не написав лишнюю копию - просто перешлем ее:
$ pv -s 50g -S -pteba /dev/zero | tee | cat > /dev/null
50GiB 0:00:20 [2.44GiB/s] [===============================================>] 100%
Так что это немного медленнее, и он даже ничего не делал! Это накладные расходы на внутреннее копирование STDIN в STDOUT. (Интересно, что добавление секунды pvостается на скорости 5,19 ГБ / с, так что pvэто значительно быстрее, чем tee. pvИспользует splice(2), teeскорее всего, нет.)
В любом случае, давайте посмотрим, что произойдет, если я скажу teeзаписать файл на диск. Он запускается довольно быстро (~ 800 МБ / с), но по мере замедления продолжает замедляться - в конечном счете, до ~ 100 МБ / с, что составляет в основном 100% пропускной способности записи на диск. (Быстрый запуск происходит из-за того, что ядро кэширует запись на диск, а замедление до скорости записи на диск приводит к отказу ядра в бесконечном росте кеша.)
Это имеет значение?
Выше приведен худший случай. Выше используется канал для выброса данных как можно быстрее. Единственное реальное использование, о котором я могу думать, это передача необработанных данных YUV в / из ffmpeg.
Когда вы отправляете данные с более низкой скоростью (потому что вы их обрабатываете и т. Д.), Это будет гораздо менее значительным эффектом.