¿El uso de -v (detallado) ralentiza los comandos?

En esta pregunta: ¿Cómo eliminar todos los archivos y subdirectorios en un directorio SIN eliminar el directorio en bash? se le pregunta cómo eliminar todos los archivos de una carpeta y no la carpeta en sí.

La excelente respuesta de Matt incluye el uso de la bandera -v para el comando 'rm'.

rm -rfv dontDeleteMe && mkdir dontDeleteMe

El comando que dejé fue el de arriba. Ciertamente útil, pero ¿el indicador -v en 'rm' y / o en general ralentiza las tareas realizadas a través de la línea de comando?

Tengo una carpeta con archivos .txt (alrededor de 100.000 de ellos) que he creado, eliminado y recreado para mí algunas veces. Algunas veces con rm, algunas veces en el buscador de archivos, y tengo la sensación de que es aún más lento usar el comando rm como se muestra arriba. ¿La bandera -v tiene algo que ver con esto?

command-line rm

— Eiriks
fuente

Respuestas:

Sí, la bandera -v ralentiza el comando.

La mayoría, si no todos los softwares (o comandos) verificarían si se proporciona un indicador, y luego ejecutarían un montón de código relacionado con el indicador. En el caso del indicador -v, es probable que ejecuten un montón de comandos de salida (comoecho o printf), que preferirían haberse omitido sin el indicador.

Esto significa más ciclos de instrucción para el procesador y, por lo tanto, más tiempo de ejecución.

Es mejor si no usa el indicador -v si no va a leer / necesitar los mensajes.

Por otro lado, la CLI debería / debería ser más rápida que la GUI, suponiendo que no incluya el tiempo requerido para escribir los comandos y presionar el Enter tecla.

Desde este blog de superusuario esta imagen explica muy bien la lentitud

ingrese la descripción de la imagen aquí

Para el comando específico en cuestión, los resultados del comando de tiempo son

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

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

Esto se hizo con el directorio que contiene 100000 archivos vacíos

— usuario registrado
fuente

No hablaría de "comandos de eco". La mayoría de los programas no son scripts de bash, por lo que no llaman a echo. El problema es que están escribiendo en stdout (o stderr ), en otras palabras, están realizando operaciones de E / S, que requieren tiempo (la E / S es costosa) y también requieren llamadas al sistema (lo que significa más cambios de contexto y, por lo tanto, más caché señorita, etc.).

— Bakuriu

El principal problema con la escritura en stdout es la representación real de ese contenido; si redirige stdout a un archivo, o el /dev/nullrendimiento no se ve tan dificil como mostrar texto en un emulador de terminal.

— Jacob Krall

Como puede ver en el gráfico, la diferencia en el tiempo es insignificante si habla del tiempo de respuesta desde el punto de vista humano. Por lo tanto, si le preocupa la eficiencia de una persona que observa el comando, no es relevante. Solo es relevante para una gran cantidad de archivos o para muchas ejecuciones repetidas donde el tiempo de la computadora es valioso (por ejemplo, un servidor web ocupado o una computadora antigua).

— Paddy Landau

El mayor impacto, y probablemente el único caso en el que realmente importaría, es cuando ejecuta el comando en una máquina remota a través de SSH. El registro detallado puede generar fácilmente decenas de megabytes de tráfico que tendrían que transmitirse desde el host a su consola. Una vez experimenté una aceleración del orden de 10x después de eliminar el registro excesivo de la consola de un script que ejecuté a través de SSH.

— Sergey

¿Por qué no descubrirlo usted mismo? Use el tiempo.

$ 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
fuente

Esto realmente no responde la pregunta. Una diferencia de 1 ms entre ejecuciones individuales de cada comando podría deberse a muchos factores. Tampoco está claro si omitió la -vsalida o si el directorio estaba vacío.

Sin mencionar que la desaceleración no se debe a las instrucciones adicionales ejecutadas, sino al proceso de escritura en un archivo o terminal. time' pretty much redirects the output to / dev / null '.

— Cole Johnson