Por que há uma diferença na duração da execução do comando com diferentes métodos de redirecionamento?

Question

Estou executando um comando find com tempo como usuário normal.

O que eu sei é que o redirecionamento é para evitar mensagens stdout / stderr no terminal. Se esse for o caso, por que os diferentes métodos de redirecionamento levam quantidades diferentes de tempo? É de alguma forma relacionada com a velocidade de escrita no tty ou existe alguma outra razão por trás disso? Alguém poderia me apontar na direção certa para entender isso?

$ 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

Quando o seu processo ( find ) precisa realmente escrever a saída, isso obviamente demora muito mais do que quando você diz para descartar a saída.

• Quando você usa find / , tanto o stdout quanto o stderr são enviados para o seu terminal, e ele tem que escrever ambos (ou seja, os resultados reais e todos os erros de permissão e outros)

• Quando você usa time find / >/dev/null , está descartando a saída padrão do comando, mas ainda imprime todos os erros (se tiver algum). A julgar pelos seus resultados, você tem muitos resultados legítimos e muito poucos erros.

• Quando você usa time find / 2> /dev/null , a saída padrão do comando ainda está sendo enviada para o seu terminal, mas agora você está simplesmente removendo o stderr. Se você estivesse encontrando através de um sistema de arquivos que você não tinha permissão para ler, isso seria realmente muito rápido.

• Quando você usa time find / > /dev/null 2>&1 , está descartando a saída padrão e, em seguida, envia um erro padrão para onde a saída padrão está sendo enviada, ou seja, você está descartando os dois. Isso não produzirá nada e, portanto, será o mais rápido de todos os comandos.

Answer 2

What I know is that redirection is to prevent stdout/stderr messages on the terminal.

Bem, não: você também pode redirecionar para um arquivo:

find / > ~/all-the-files

Is it somehow related to the write speed on the tty?

Em uma palavra, sim.

Independentemente do tipo de terminal que você está usando (console virtual no Linux, um xterm local, algo em uma conexão SSH), o emulador de terminal real tem que desenhar tudo impresso no terminal, mesmo que neste caso seja vai rolar para fora em breve. (Uma conexão acima de mosh pode ser uma exceção aqui.)

Em uma conexão de rede, há também o atraso de transferência a considerar, alguns dados podem ser armazenados em buffer, se houver muitos, nem todos. Se você redirecionar algo para /dev/null , ele não será salvo em lugar algum e nem será desenhado. Redirecionar para um arquivo também será rápido com quantidades moderadas de dados, já que o sistema operacional provavelmente armazena as gravações na memória, e só grava no disco depois. Com uma grande quantidade de dados, gravar no disco também pode se tornar um gargalo. (ou, se você conseguiu que o processo escreva a saída no modo de E / S síncrona)

Para programas que produzem muitos resultados, apenas o processo de formatação da saída ( printf() dentro do processo) e a chamada para o SO para escrevê-lo levaria tempo, mesmo se os dados fossem redirecionados para /dev/null . Em um caso como esse, pode ser ainda mais rápido se você conseguir persuadir o programa a inibir a saída completamente. Este provavelmente não é o caso de find , eu suponho que seria ligado a velocidade de E / S ou a sobrecarga de chamada do sistema.

Observe também que, se você executar find na mesma árvore de diretórios repetidamente, a primeira vez provavelmente será mais lenta que as outras, já que a primeira vez pode requerer leitura do disco, e depois disso, grande parte dos dados será armazenado em cache pelo sistema operacional.