¿Ejecutar comandos de forma detallada los hace más lentos?

37

Me he encontrado usando la -vbandera para muchas aplicaciones cada vez menos (especialmente para cosas triviales como tary cp). Sin embargo, cuando lo hice y estaba, por ejemplo, descomprimiendo un archivo grande, me llevó más tiempo que cuando no usé la -vbandera.

Supongo que esto se debe a que el terminal tiene que procesar el texto y estoy llenando cualquier búfer que pueda tener. Pero mi pregunta es, ¿esto hace que la aplicación se ejecute más lentamente o se completa en la misma cantidad de tiempo y lo que veo es que el terminal intenta ponerse al día?

linux unix shell

— n0pe
fuente

¿Trató de tiempo, por ejemplo tar xvf file.tar > /dev/nullfrente tar xf file.tar? Redirigir a /dev/nulldebería sacar su terminal de esto.

— Benjamin Bannier

3

Además, tenga en cuenta que stdouty stderrestán con buffer de línea , lo que significa que llenar los buffers no toma tanto tiempo, son las printfllamadas de bloqueo (y por la salida del terminal de extensión) lo que toma una eternidad.

— nuevo123456

1

Si hubieras hablado de comandos de Windows, diría sin duda que es verdad :)

— kokbira

Para la tarea intensiva de la CPU, dependiendo de cuánto IO esté haciendo, puede ver una horrible degradación del rendimiento.

— usuario

31

Sí, ejecutar verbose ralentizará sus aplicaciones.

Cuánto depende de la aplicación.

Cada impresión en el terminal requerirá un tiempo de procesamiento adicional. En el caso de usar printf () o cualquiera de sus hermanas, esta es una gran cantidad de procesamiento desperdiciado.

Además, el terminal tiene que lidiar con esos datos. Hay una cantidad limitada de espacio en el búfer entre la aplicación y el terminal, y el canal de E / S se bloqueará hasta que haya suficiente espacio en dicho búfer para emitir los datos. Por lo general, la aplicación no podrá continuar mientras se realiza este bloqueo. ¹

Además, el acto de mostrar el texto de depuración en el terminal consumirá ciclos de procesamiento. Nuevamente, esto depende tanto de la aplicación (la cantidad de depuración), el programa del terminal (fuentes utilizadas, efectos, etc.) e incluso el controlador X windows en uso (aceleración de hardware, etc.).

El timeprograma se puede usar para determinar con bastante precisión cuánto tiempo ha tardado en ejecutarse un comando. Ejecutar el mismo programa dos veces a lo largo del tiempo, una vez con depuración y una vez sin, le mostrará la diferencia que hace. Sugeriría ejecutar el comando una vez antes de realizar las pruebas para garantizar que el almacenamiento en caché sea el mismo para ambas ejecuciones de prueba del comando. No desea sesgar los resultados al hacer que la segunda ejecución vaya mucho más rápido porque la mayoría de los datos fueron almacenados en caché por la primera ejecución ahora, ¿no ...

¹ En el caso de una aplicación multiproceso, solo se bloqueará el hilo que realiza la salida de depuración.

— Majenko
fuente

La mayoría de los programadores aprenden esto bastante rápido (Borland C en DOS);)

— Dragos

Por supuesto, si la ventana de la consola está oculta (o incluso parcialmente cubierta), no afectará tanto como cuando la consola está visible. Abra un símbolo del sistema y haga un dir c:\/s/a. Puede ver el cambio de velocidad cuando es completamente visible y parcialmente cubierto. No puede ver que se acelera cuando se minimiza, pero definitivamente es más rápido, aunque tendría que reiniciar si quisiera probar, para evitar el almacenamiento en caché, lo que lo haría más rápido de todos modos, ya que no habría para acceder al disco.

— Synetech

1

@Syn Estamos hablando de Linux aquí.

— Majenko

1

@Matt sigue siendo un comentario válido. Por favor se respetuoso.

— nhinkle

@ Matt, doh! No me di cuenta. (Tal vez me distraje del comentario de DOS.) De todos modos, Linux es bastante diferente, pero me pregunto si lo mismo es cierto (consolas visibles con mucho desplazamiento de texto más lento).

— Synetech

8

Depende de la aplicación que esté ejecutando. Sin embargo, en general, podemos decir que verbose ralentizará las aplicaciones de Linux más comunes, ya que deben sincronizar sus acciones entre stdout y E / S o límites del procesador.

— Diogo
fuente

6

Utilizando yescomo un caso de prueba en OS X 10.7, parece que realmente importa si imprime una gran cantidad de resultados en el terminal, como era de esperar.

Cuantificando esto un poco más, ejecuté yesdurante 5 segundos, en un caso imprimí la salida en el terminal y la guardé en un archivo (con tee), en el otro caso hice lo mismo excepto redirigir stdouta /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

El caso 1. da 2371584 líneas y el caso 2. da 136421376 líneas, o 57 veces más. En este caso, el "rendimiento" de yes(medido por la cantidad de líneas que imprime por unidad de tiempo) es 57 veces más lento .

Una nota al margen aquí es que utilicé yesjunto con teeaquí, lo que podría influir ligeramente en los resultados, sin embargo, creo que los resultados aún son válidos.

Otra indicación de que el programa se ralentiza es que se ejecuta yesmientras se emite a un terminal, el terminal usa alrededor del 100% de CPU y yessolo alrededor del 37%, mientras se ejecuta yessin salir a un terminal, usa el 100% completo (esto es en un multi- núcleo de la máquina, por lo que yespodría usar más CPU si pudiera, excepto que el terminal lo desaceleró).

— Tim
fuente

5

Es fácil responder que sí, ralentizará la aplicación. Pero una respuesta mucho más verdadera es que no importará en el 99% de los casos.

Si su aplicación está haciendo algún tipo de trabajo que realmente requiere algo de energía de la CPU, las posibilidades de imprimir algunas líneas de texto adicionales en la pantalla que marquen algún tipo de diferencia son cercanas al 0%.

De hecho, puede hacer su propio juicio fácilmente: si la aplicación está arrojando un inmenso muro de texto, en realidad podría costarle un poco. Tal vez.

— slarpspark
fuente

3

-1 esto simplemente no es cierto. printf()es increíblemente caro

— Thomas Bonini

1

Lo que dije fue verdad. Sin embargo, lo que está tratando de hacer que parezca que dije es algo completamente diferente. No estoy diciendo nada sobre la eficiencia de ninguna impresión estándar de stdlib. Estoy diciendo que los programas deberían estar haciendo suficiente trabajo para que el tiempo dedicado a imprimir sea insignificante. Ahora ve a troll a alguien más.

— slarpspark

@slarpspark: no es necesariamente insignificante, incluso si eliminamos printf () de la ecuación, el flujo de bytes todavía tiene que pasar por bash, luego el emulador de terminal, luego el emulador de terminal tuvo que mostrar el texto en la pantalla después de analizar los caracteres de escape, y la representación de texto no es barata si se realiza a la velocidad que algunos comandos detallados podrían hacer; y sería especialmente costoso si el programa descarga el búfer de salida en cada línea, ya que eso significa cambios de contexto. A menudo, al escribir scripts de Python, a menudo, al eliminar las impresiones en bucle cerrado, a veces puede llevar 10s a 1s.

— Lie Ryan

¿Qué pasa con un comando que se ejecuta sobre SSH, incluso si el tiempo de CPU es mínimo, una vez que introduce la latencia de la red, seguramente eso es significativo?

— ec2011

3

Un código detallado generalmente se evalúa con una instrucción if y cada vez que pasa el control a una función de visualización, más tiempo tarda, el contexto puede cambiar, más interrupciones.

Pero depende, si el código detallado es un hilo separado que solo verifica el estado de finalización de vez en cuando, la diferencia es despreciable.

Esta pregunta puede beneficiarse mucho de la contribución de los programadores experimentados de stackoverflow. Sugiero mudarse :)

— Dragos
fuente