Sim, isso atrasa as coisas. E basicamente tem uma fila de dados não gravados, embora isso realmente seja mantido pelo kernel - todos os programas têm isso, a menos que solicitem explicitamente o contrário.
Por exemplo, aqui está um pipe trivial usando pv , o que é legal porque exibe a taxa de transferência:
$ pv -s 50g -S -pteba /dev/zero | cat > /dev/null
50GiB 0:00:09 [ 5.4GiB/s] [===============================================>] 100%
Agora, vamos adicionar um tee lá, nem mesmo escrever uma cópia extra - apenas encaminhá-lo:
$ pv -s 50g -S -pteba /dev/zero | tee | cat > /dev/null
50GiB 0:00:20 [2.44GiB/s] [===============================================>] 100%
Então, isso é um pouco mais lento e não estava nem fazendo nada! Essa é a sobrecarga de tee internamente copiando STDIN para STDOUT. (Curiosamente, adicionar um segundo pv nele permanece em 5.19GiB / s, portanto pv é substancialmente mais rápido que tee . pv usa splice(2) , tee provavelmente não.)
De qualquer forma, vamos ver o que acontece se eu disser tee para gravar em um arquivo no disco. Ele começa razoavelmente rápido (~ 800MiB / s), mas à medida que continua, ele continua diminuindo - em última análise, para ~ 100MiB / s, que é basicamente 100% da largura de banda de gravação de disco. (O início rápido é devido ao cache do kernel na gravação do disco, e a lentidão na velocidade de gravação do disco é o kernel recusando deixar o cache crescer infinitamente.)
Isso importa?
O acima é o pior caso. O acima usa um pipe para liberar dados o mais rápido possível. O único uso do mundo real que eu posso pensar assim é a transmissão de dados YUV brutos para / de ffmpeg .
Quando você envia dados a taxas mais lentas (porque você os está processando etc.), isso terá um efeito muito menos significativo.