Al giorno d'oggi, imo, non c'è motivo di usare time a scopo di benchmarking. Usa perf stat invece. Ti dà informazioni molto più utili e può ripetere il processo di benchmarking un dato numero di volte e fare statistiche sui risultati, cioè calcolare la varianza e il valore medio. Questo è molto più affidabile e altrettanto semplice da usare di time :
perf stat -r 10 -d <your app and arguments>
Il -r 10 eseguirà la tua app 10 volte e farà statistiche su di essa. -d genera altri dati, come cache miss.
Quindi, mentre time potrebbe essere abbastanza affidabile per applicazioni di lunga durata, sicuramente non è affidabile come perf stat . Usa quello invece.
Appendice: Se vuoi davvero continuare a usare time , almeno non usare il comando bash-builtin, ma il vero affare in modalità dettagliata:
/usr/bin/time -v <some command with arguments>
L'output è quindi, ad esempio:
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
Si noti in particolare come questo sia in grado di misurare il picco RSS, che spesso è sufficiente se si desidera confrontare l'effetto di una patch sul consumo massimo di memoria. Cioè. usa quel valore per confrontare prima/dopo e se c'è una diminuzione significativa del picco RSS, allora hai fatto qualcosa di giusto.
time produce tempi abbastanza buoni per i benchmark che durano più di un secondo altrimenti il tempo impiegato exec() ing di un processo può essere grande rispetto al suo tempo di esecuzione.
Tuttavia, durante il benchmarking dovresti fare attenzione al cambio di contesto. Cioè, un altro processo potrebbe utilizzare la CPU contendendo così la CPU con il tuo benchmark e aumentandone il tempo di esecuzione. Per evitare conflitti con altri processi, dovresti eseguire un benchmark come questo:
sudo chrt -f 99 /usr/bin/time --verbose <benchmark>
Oppure
sudo chrt -f 99 perf stat -ddd <benchmark>
sudo chrt -f 99 esegue il tuo benchmark nella classe FIFO in tempo reale con priorità 99, che rende il tuo processo il processo con la massima priorità ed evita il cambio di contesto (puoi cambiare il tuo /etc/security/limits.conf in modo che non richieda un processo privilegiato per utilizzare le priorità in tempo reale).
Rende anche time riporta tutte le statistiche disponibili, incluso il numero di cambi di contesto sostenuti dal tuo benchmark, che normalmente dovrebbe essere 0, altrimenti potresti voler eseguire nuovamente il benchmark.
perf stat -ddd è ancora più informativo di /usr/bin/time e visualizza informazioni come istruzioni per ciclo, fallimenti di branch e cache, ecc.
Ed è meglio disabilitare il ridimensionamento e l'aumento della frequenza della CPU, in modo che la frequenza della CPU rimanga costante durante il benchmark per ottenere risultati coerenti.