O uso de -v (detalhado) torna lento os comandos?

Nesta pergunta: Como remover todos os arquivos e subdiretórios em um diretório SEM excluir o diretório no bash? é perguntado como excluir todos os arquivos em uma pasta, e não a própria pasta.

A resposta excelente de Matt inclui o uso do sinalizador -v no comando 'rm'.

rm -rfv dontDeleteMe && mkdir dontDeleteMe

O comando que eu deixei com foi o acima. Certamente útil, de fato, mas o sinalizador -v em 'rm' e / ou, em geral, diminui as tarefas realizadas pela linha de comando?

Eu tenho uma pasta com arquivos .txt (cerca de 100.000 deles) que criei, excluí e recriei para mim algumas vezes agora. Algumas vezes com rm, outras no navegador de arquivos, e sinto que é ainda mais lento usar o comando rm como mostrado acima. O sinalizador -v tem algo a ver com isso?

command-line rm

— Eiriks
fonte

Respostas:

Sim, o sinalizador -v reduz a velocidade do comando.

A maioria, se não todos os softwares (ou comandos), verificariam se um sinalizador é fornecido e, em seguida, executariam um monte de código relacionado ao sinalizador. No caso do sinalizador -v, eles provavelmente executariam vários comandos de saída (como echoou printf), que prefeririam ignorar sem o sinalizador.

Isso significa mais ciclos de instruções para o processador e, portanto, mais tempo de execução.

É melhor se você não usar o sinalizador -v se não quiser ler / precisar das mensagens.

Por outro lado, a CLI seria / deveria ser mais rápida que a GUI, supondo que você não inclua o tempo necessário para digitar os comandos e pressionar a Entertecla.

A partir deste blog de superusuário esta imagem explica a lentidão muito bem

insira a descrição da imagem aqui

Para o comando específico em questão, os resultados do comando time são

//with -v
real    0m8.753s
user    0m0.816s
sys     0m2.036s

//without -v
real    0m1.282s
user    0m0.124s
sys     0m1.092s

isso foi feito com o diretório que contém 100000 arquivos vazios

— Usuário Registrado
fonte

Eu não falaria de "comandos de eco". A maioria dos programas não são scripts bash, portanto, não chamam eco. O problema é que eles estão gravando no stdout (ou stderr ), ou seja, estão executando operações de E / S, que exigem tempo (E / S é dispendiosa) e também exigem chamadas do sistema (o que significa mais comutações de contexto e, portanto, mais falta de cache etc.).

— Bakuriu

O principal problema com a gravação no stdout é a renderização real desse conteúdo; se você redirecionar stdout para um arquivo, ou /dev/null, o desempenho não será tão prejudicado quanto a exibição de texto em um emulador de terminal.

— 26630 Jacob Krall

Como você pode ver no gráfico, a diferença de tempo é insignificante se você estiver falando sobre o tempo de resposta do ponto de vista humano. Portanto, se você está preocupado com a eficiência de uma pessoa que assiste ao comando, isso não é relevante. É relevante apenas para um grande número de arquivos ou para muitas execuções repetidas em que o tempo do computador é precioso (por exemplo, um servidor Web ocupado ou um computador antigo).

— Paddy Landau

O maior impacto, e provavelmente o único caso em que isso realmente importa, é quando você executa o comando em uma máquina remota via SSH. O log detalhado pode gerar facilmente dezenas de megabytes de tráfego que precisariam ser transmitidos do host para o console. Certa vez, experimentei uma aceleração na ordem de 10x depois de remover o log excessivo do console de um script que eu executei via SSH.

— Sergey

Por que não se descobrir: use o tempo.

$ time rm -rfv dontDeleteMe && mkdir dontDeleteMe
real    0m0.003s
user    0m0.001s
sys     0m0.002s

$ time rm -rf dontDeleteMe && mkdir dontDeleteMe
real    0m0.002s
user    0m0.001s
sys     0m0.001s

— sethmuss
fonte

Isso realmente não responde à pergunta. Uma diferença de 1 ms entre execuções únicas de cada comando pode ser causada por vários fatores. Também não está claro se você omitiu a -vsaída ou o diretório estava vazio.

Sem mencionar que o abrandamento não está nas instruções extra executadas, mas no processo de gravá-lo em um arquivo ou no terminal. time' pretty much redirects the output to / dev / null '.

— Cole Johnson