Heutzutage gibt es meiner Meinung nach keinen Grund, time zu verwenden zu Benchmarking-Zwecken. Verwenden Sie perf stat stattdessen. Es gibt Ihnen viel nützlichere Informationen und kann den Benchmarking-Prozess beliebig oft wiederholen und Statistiken über die Ergebnisse erstellen, dh Varianz und Mittelwert berechnen. Dies ist viel zuverlässiger und genauso einfach zu verwenden wie time :
perf stat -r 10 -d <your app and arguments>
Die -r 10 wird Ihre App 10 Mal ausführen und Statistiken darüber erstellen. -d gibt einige weitere Daten aus, wie z. B. Cache-Fehler.
Also während time für Anwendungen mit langer Laufzeit zuverlässig genug sein könnte, ist es definitiv nicht so zuverlässig wie perf stat . Verwenden Sie stattdessen das.
Nachtrag: Wenn Sie time wirklich weiter verwenden möchten , verwenden Sie zumindest nicht den bash-builtin-Befehl, sondern den Real-Deal im Verbose-Modus:
/usr/bin/time -v <some command with arguments>
Die Ausgabe ist dann z. B.:
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
Beachten Sie insbesondere, dass dies in der Lage ist, den Spitzen-RSS zu messen, was häufig ausreicht, wenn Sie die Auswirkung eines Patches auf den Spitzenspeicherverbrauch vergleichen möchten. D.h. Verwenden Sie diesen Wert, um vorher/nachher zu vergleichen, und wenn der RSS-Peak deutlich abnimmt, haben Sie etwas richtig gemacht.
time erzeugt gut genug Zeiten für Benchmarks, die über eine Sekunde laufen, ansonsten die Zeit, die es exec() gedauert hat Das Speichern eines Prozesses kann im Vergleich zu seiner Laufzeit groß sein.
Allerdings sollte man beim Benchmarking auf Kontextwechsel achten. Das heißt, ein anderer Prozess kann die CPU verwenden und somit mit Ihrem Benchmark um die CPU konkurrieren und seine Laufzeit erhöhen. Um Konflikte mit anderen Prozessen zu vermeiden, sollten Sie einen Benchmark wie diesen ausführen:
sudo chrt -f 99 /usr/bin/time --verbose <benchmark>
Oder
sudo chrt -f 99 perf stat -ddd <benchmark>
sudo chrt -f 99 führt Ihren Benchmark in der FIFO-Echtzeitklasse mit Priorität 99 aus, was Ihren Prozess zum Prozess mit der höchsten Priorität macht und Kontextwechsel vermeidet (Sie können Ihren /etc/security/limits.conf ändern sodass kein privilegierter Prozess erforderlich ist, um Echtzeitprioritäten zu verwenden).
Es macht auch time Melden Sie alle verfügbaren Statistiken, einschließlich der Anzahl der Kontextwechsel, die Ihr Benchmark verursacht hat, was normalerweise 0 sein sollte, andernfalls möchten Sie den Benchmark vielleicht erneut ausführen.
perf stat -ddd ist noch informativer als /usr/bin/time und zeigt Informationen wie Anweisungen pro Zyklus, Verzweigungs- und Cache-Fehlschläge usw. an.
Und es ist besser, die CPU-Frequenzskalierung und -anhebung zu deaktivieren, damit die CPU-Frequenz während des Benchmarks konstant bleibt, um konsistente Ergebnisse zu erhalten.