A execução de comandos verbalmente os torna mais lentos?

37

Eu me peguei usando a -vflag para muitas aplicações cada vez menos (especialmente para coisas triviais como tare cp). No entanto, quando fiz e descompactei um arquivo grande, levaria mais tempo do que quando não usei o -vsinalizador.

Suponho que isso ocorre porque o terminal precisa processar o texto e estou preenchendo qualquer buffer que possa ter. Mas minha pergunta é: isso torna o aplicativo realmente mais lento ou é concluído na mesma quantidade de tempo e o que estou vendo é que o terminal está tentando recuperar o atraso?

linux unix shell

— n0pe
fonte

Você tentou tempo eg tar xvf file.tar > /dev/nullvs. tar xf file.tar? Redirecionar para /dev/nulldeve tirar seu terminal disso.

— Benjamin Bannier

3

Além disso, observe que stdoute stderrsão com buffer de linha - o que significa que o preenchimento de buffers não leva tanto tempo - são as printfchamadas de bloqueio (e pela saída do terminal de extensão) que levam uma eternidade.

— New123456

1

Se você tinha falado sobre comandos do Windows, eu diria com certeza que é verdade :)

— kokbira

Para tarefas intensivas da CPU, dependendo da quantidade de IO que você está fazendo, poderá ocorrer uma degradação horrível do desempenho.

— usuário

31

Sim, a execução detalhada reduzirá a velocidade de seus aplicativos.

Quanto depende da aplicação.

Toda impressão no terminal exigirá tempo de processamento extra. No caso de usar printf () ou qualquer uma de suas irmãs, essa é uma quantidade bastante pesada de processamento desperdiçado.

Além disso, o terminal precisa lidar com esses dados. Há uma quantidade limitada de espaço no buffer entre o aplicativo e o terminal, e o canal IO será bloqueado até que haja espaço suficiente no referido buffer para realmente enviar os dados. O aplicativo geralmente não poderá continuar enquanto esse bloqueio estiver ocorrendo. ^{1 1}

Além disso, o ato de exibir o texto de depuração no terminal consumirá ciclos de processamento. Novamente, isso depende da aplicação (a quantidade de depuração), do programa do terminal (fontes usadas, efeitos, etc.) e até do driver do Windows X em uso (aceleração de hardware, etc.).

O timeprograma pode ser usado para determinar com bastante precisão quanto tempo um comando levou para ser executado. A execução do mesmo programa duas vezes no tempo, uma vez com depuração e outra sem, mostrará a diferença. Sugiro executar o comando uma vez antes de executar os testes para garantir que o cache seja o mesmo para as duas execuções de teste do comando. Você não deseja distorcer os resultados fazendo com que a segunda execução seja muito mais rápida, porque a maioria dos dados foi armazenada em cache pela primeira execução agora.

¹ No caso de um aplicativo multithread, apenas o thread que executa a saída de depuração será realmente bloqueado.

— Majenko
fonte

A maioria dos programadores aprende este jejum bonita (Borland C em DOS);)

— Dragos

Obviamente, se a janela do console estiver oculta (ou mesmo parcialmente coberta), ela não afetará tanto quanto quando o console estiver visível. Abra um prompt de comando e faça um dir c:\/s/a. Você pode ver a velocidade mudar quando estiver completamente visível e parcialmente coberta. Você não pode vê- lo acelerar quando minimizado, mas é definitivamente mais rápido, embora você precise reiniciar se quiser testar, a fim de ignorar o cache que faria com que fosse mais rápido de qualquer maneira, já que não teria para acessar o disco.

— Synetech 8/08/11

1

@ Syn Nós estamos falando de Linux aqui.

— Majenko 8/08/11

1

@ Matt ainda é um comentário válido. Por favor, seja respeitoso.

— Nhinkle

@ Matt, doh! Eu não percebi. (Talvez eu tenha me distraído com o comentário do DOS.) De qualquer forma, o Linux é bem diferente, mas me pergunto se o mesmo se aplica a ele (consoles visíveis com muito texto rolando mais devagar).

— Synetech

8

Depende do aplicativo que você está executando. No entanto, em geral, podemos dizer que o detalhado abrandará os aplicativos Linux mais comuns, pois eles devem sincronizar suas ações entre stdout e E / S ou limites do processador.

— Diogo
fonte

6

Usando yescomo um caso de teste no OS X 10.7, parece realmente importante se você imprimir muita saída no terminal, como seria de esperar.

Quantificando isso um pouco mais, corri yespor 5 segundos, em um caso imprimindo a saída no terminal e salvando-a em um arquivo (com tee), no outro caso, fazendo o mesmo, exceto redirecionando stdoutpara /dev/null:

yes | tee yeslog_term & sleep 5 && killall yes && wc -l yeslog_term
yes | tee yeslog_noterm > /dev/null & sleep 5 && killall yes && wc -l yeslog_noterm

O caso 1. fornece 2371584 linhas e o caso 2. fornece 136421376 linhas, ou 57 vezes mais. O 'desempenho' de yes(medido pela quantidade de linhas impressas por unidade de tempo) é, nesse caso, 57 vezes mais lento .

Uma observação lateral aqui é que eu usei yesem conjunto com teeaqui, o que pode influenciar um pouco os resultados, no entanto, acho que os resultados ainda são válidos.

Outra indicação de que o programa está mais lento é que, rodando yesdurante a saída para um terminal, o terminal usa cerca de 100% da CPU e yesapenas cerca de 37%, enquanto rodando yessem saída para um terminal, ele usa 100% (Isso é feito em máquina principal, então yespoderia usar mais CPU, se fosse capaz, exceto pelo fato de ter sido mais lento pelo terminal).

— Tim
fonte

5

É fácil apenas responder que sim, isso atrasará o aplicativo. Mas uma resposta muito mais verdadeira é que não importará em 99% dos casos.

Se o seu aplicativo estiver realizando algum tipo de trabalho que realmente consome alguma energia da CPU, as chances de imprimir algumas linhas de texto extras na tela fazendo qualquer tipo de diferença são próximas de 0%.

Na verdade, você pode facilmente fazer seu próprio julgamento: se o aplicativo estiver lançando uma imensa parede de texto, poderá custar um pouco. Talvez.

— slarpspark
fonte

3

-1 isso não é verdade. printf()é insanamente caro

— Thomas Bonini

1

O que eu disse era verdade. O que você está tentando fazer parecer que eu disse, no entanto, é algo completamente diferente. Não estou dizendo nada sobre a eficiência de qualquer impressão stdlib específica. Estou dizendo que os programas devem estar fazendo o trabalho suficiente para que o tempo gasto na impressão seja insignificante. Agora vá trollar alguém.

— Slarpspark

@slarpspark: não é necessariamente desprezível, mesmo se tirarmos printf () da equação, o fluxo de bytes ainda precisará passar pelo bash, depois pelo emulador de terminal e depois pelo emulador de terminal para renderizar o texto na tela depois de analisar os caracteres de escape, e a renderização de texto não é barata se for feita na velocidade que alguns comandos detalhados podem fazer; e seria especialmente caro se o programa liberasse o buffer de saída em todas as linhas, pois isso significa alternância de contexto. Costumo experimentar enquanto escrevia scripts python, que a remoção de impressões em loop apertado às vezes pode levar de 10s a 1s.

— Lie Ryan

Que tal um comando executando sobre SSH, mesmo que o tempo da CPU seja mínimo, depois de introduzir a latência da rede, isso é significativo?

— ec2011

3

Um código detalhado é geralmente avaliado com uma instrução if e toda vez que passa o controle para uma função de exibição, quanto mais tempo leva, o contexto pode ser alterado, mais interrupções.

Mas isso depende, se o código detalhado for um encadeamento separado que está apenas verificando o estado de conclusão de tempos em tempos, a diferença é negligenciável.

Esta questão pode se beneficiar muito da contribuição dos programadores experientes do stackoverflow. Sugiro mudar :)

— Dragos
fonte