De nos jours, imo, il n'y a aucune raison d'utiliser time à des fins d'étalonnage. Utilisez perf stat Au lieu. Il vous donne beaucoup plus d'informations utiles et peut répéter le processus d'analyse comparative un certain nombre de fois et faire des statistiques sur les résultats, c'est-à-dire calculer la variance et la valeur moyenne. C'est beaucoup plus fiable et aussi simple à utiliser que time :
perf stat -r 10 -d <your app and arguments>
Le -r 10 exécutera votre application 10 fois et effectuera des statistiques dessus. -d génère davantage de données, telles que les échecs de cache.
Alors que time peut être suffisamment fiable pour les applications de longue durée, il n'est certainement pas aussi fiable que perf stat . Utilisez-le à la place.
Avenant : Si vous voulez vraiment continuer à utiliser time , au moins n'utilisez pas la commande bash-builtin, mais la vraie affaire en mode verbeux :
/usr/bin/time -v <some command with arguments>
La sortie est alors par exemple :
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
Notez surtout comment cela est capable de mesurer le pic RSS, ce qui est souvent suffisant si vous voulez comparer l'effet d'un patch sur le pic de consommation mémoire. C'est à dire. utilisez cette valeur pour comparer avant/après et s'il y a une diminution significative du pic RSS, alors vous avez fait quelque chose de bien.
time produit des temps assez bons pour les benchmarks qui s'exécutent sur une seconde sinon le temps qu'il a fallu exec() ing un processus peut être volumineux par rapport à son temps d'exécution.
Cependant, lors de l'analyse comparative, vous devez faire attention au changement de contexte. C'est-à-dire qu'un autre processus peut utiliser le CPU, rivalisant ainsi pour le CPU avec votre référence et augmentant son temps d'exécution. Pour éviter les conflits avec d'autres processus, vous devez exécuter un benchmark comme celui-ci :
sudo chrt -f 99 /usr/bin/time --verbose <benchmark>
Ou
sudo chrt -f 99 perf stat -ddd <benchmark>
sudo chrt -f 99 exécute votre benchmark en classe FIFO temps réel avec la priorité 99, ce qui fait de votre processus le processus prioritaire et évite le changement de contexte (vous pouvez changer votre /etc/security/limits.conf afin qu'il ne nécessite pas un processus privilégié pour utiliser les priorités en temps réel).
Cela fait aussi time rapportez toutes les statistiques disponibles, y compris le nombre de changements de contexte subis par votre benchmark, qui devrait normalement être de 0, sinon vous voudrez peut-être réexécuter le benchmark.
perf stat -ddd est encore plus informatif que /usr/bin/time et affiche des informations telles que les instructions par cycle, les sauts de branche et de cache, etc.
Et il est préférable de désactiver la mise à l'échelle et l'amplification de la fréquence du processeur, afin que la fréquence du processeur reste constante pendant le benchmark pour obtenir des résultats cohérents.