Hoy en día, en mi opinión, no hay razón para usar time con fines de evaluación comparativa. Usa perf stat en cambio. Le brinda información mucho más útil y puede repetir el proceso de evaluación comparativa en cualquier cantidad de tiempo y hacer estadísticas sobre los resultados, es decir, calcular la varianza y el valor medio. Esto es mucho más confiable y tan simple de usar como time :
perf stat -r 10 -d <your app and arguments>
El -r 10 ejecutará su aplicación 10 veces y hará estadísticas sobre ella. -d genera algunos datos más, como errores de caché.
Entonces, mientras time podría ser lo suficientemente confiable para aplicaciones de ejecución prolongada, definitivamente no es tan confiable como perf stat . Usa eso en su lugar.
Anexo: Si realmente quieres seguir usando time , al menos no use el comando bash incorporado, sino el trato real en modo detallado:
/usr/bin/time -v <some command with arguments>
La salida es entonces, por ejemplo:
Command being timed: "ls"
User time (seconds): 0.00
System time (seconds): 0.00
Percent of CPU this job got: 0%
Elapsed (wall clock) time (h:mm:ss or m:ss): 0:00.00
Average shared text size (kbytes): 0
Average unshared data size (kbytes): 0
Average stack size (kbytes): 0
Average total size (kbytes): 0
Maximum resident set size (kbytes): 1968
Average resident set size (kbytes): 0
Major (requiring I/O) page faults: 0
Minor (reclaiming a frame) page faults: 93
Voluntary context switches: 1
Involuntary context switches: 2
Swaps: 0
File system inputs: 8
File system outputs: 0
Socket messages sent: 0
Socket messages received: 0
Signals delivered: 0
Page size (bytes): 4096
Exit status: 0
Tenga en cuenta especialmente cómo esto es capaz de medir el pico de RSS, que a menudo es suficiente si desea comparar el efecto de un parche en el pico de consumo de memoria. Es decir. use ese valor para comparar antes/después y si hay una disminución significativa en el pico de RSS, entonces hizo algo bien.
time produce tiempos lo suficientemente buenos para los puntos de referencia que se ejecutan en más de un segundo, de lo contrario, el tiempo que tomó exec() ejecutar un proceso puede ser grande en comparación con su tiempo de ejecución.
Sin embargo, al realizar una evaluación comparativa, debe tener cuidado con el cambio de contexto. Es decir, otro proceso puede estar usando la CPU, por lo tanto, compitiendo por la CPU con su punto de referencia y aumentando su tiempo de ejecución. Para evitar conflictos con otros procesos, debe ejecutar un punto de referencia como este:
sudo chrt -f 99 /usr/bin/time --verbose <benchmark>
O
sudo chrt -f 99 perf stat -ddd <benchmark>
sudo chrt -f 99 ejecuta su punto de referencia en la clase FIFO en tiempo real con prioridad 99, lo que hace que su proceso sea el proceso de máxima prioridad y evita el cambio de contexto (puede cambiar su /etc/security/limits.conf para que no requiera un proceso privilegiado para usar prioridades en tiempo real).
También hace time informe todas las estadísticas disponibles, incluida la cantidad de cambios de contexto en los que incurrió su punto de referencia, que normalmente debería ser 0; de lo contrario, es posible que desee volver a ejecutar el punto de referencia.
perf stat -ddd es incluso más informativo que /usr/bin/time y muestra información como instrucciones por ciclo, fallas de rama y caché, etc.
Y es mejor deshabilitar el escalado y aumento de la frecuencia de la CPU, de modo que la frecuencia de la CPU se mantenga constante durante el punto de referencia para obtener resultados consistentes.