Ist Stoppuhr-Benchmarking akzeptabel?

Verwendet jemand jemals Stoppuhr-Benchmarking oder sollte immer ein Leistungstool verwendet werden? Gibt es gute kostenlose Tools für Java? Welche Tools verwenden Sie?

Um meine Bedenken auszuräumen, kann das Stoppuhr-Benchmarking aufgrund der Betriebssystemplanung fehlerhaft sein. Bei einem bestimmten Programmlauf plant das Betriebssystem möglicherweise einen anderen Prozess (oder mehrere) in der Mitte der Funktion, die Sie planen. In Java sind die Dinge noch ein bisschen schlimmer, wenn Sie versuchen, eine Thread-Anwendung zeitlich zu steuern, da der JVM-Scheduler noch ein bisschen mehr Zufälligkeit in die Mischung bringt.

Wie gehen Sie beim Benchmarking mit der Betriebssystemplanung um?

Stoppuhr-Benchmarking ist in Ordnung, vorausgesetzt, Sie messen genügend Iterationen, um sinnvoll zu sein. Normalerweise benötige ich eine verstrichene Gesamtzeit von einigen einstelligen Sekunden. Andernfalls werden Ihre Ergebnisse durch die Planung und andere Betriebsunterbrechungen Ihres Prozesses leicht erheblich verzerrt.

Dafür verwende ich ein paar statische Methoden, die ich vor langer Zeit erstellt habe und auf denen sie basieren System.currentTimeMillis().

Für die Profilerstellung habe ich jProfiler einige Jahre verwendet und fand es sehr gut. Ich habe kürzlich YourKit durchgesehen , was auf der Website großartig zu sein scheint, aber ich habe es persönlich überhaupt nicht verwendet.

Um die Frage nach Planungsunterbrechungen zu beantworten, stelle ich fest, dass wiederholte Läufe, bis Konsistenz / Beobachtung erreicht ist, in der Praxis dazu beitragen, anomale Ergebnisse aus der Prozessplanung auszusortieren. Ich finde auch, dass die Thread-Planung für Läufe zwischen 5 und 30 Sekunden keine praktischen Auswirkungen hat. Nachdem Sie die Schwellenwertplanung für einige Sekunden überschritten haben, hat dies meiner Erfahrung nach einen vernachlässigbaren Einfluss auf die Ergebnisse. Ich stelle fest, dass ein 5-Sekunden-Lauf im Durchschnitt den gleichen Wert wie ein 5-Minuten-Lauf für Zeit / Iteration aufweist.

Möglicherweise möchten Sie den getesteten Code auch etwa 10.000 Mal vorab ausführen, um die JIT "aufzuwärmen", je nachdem, wie oft Sie erwarten, dass der getestete Code im wirklichen Leben im Laufe der Zeit ausgeführt wird.

Es ist absolut gültig, solange Sie ausreichend große Zeitintervalle messen. Ich würde 20 bis 30 Läufe von dem ausführen, was Sie testen möchten, damit die insgesamt verstrichene Zeit mehr als 1 Sekunde beträgt. Ich habe festgestellt, dass Zeitberechnungen basierend auf System.currentTimeMillis () entweder 0 ms oder ~ 30 ms betragen. Ich glaube nicht, dass Sie etwas präziseres bekommen können. Sie können System.nanoTime () ausprobieren, wenn Sie wirklich ein kleines Zeitintervall messen müssen:

• Dokumentation: http://java.sun.com/javase/6/docs/api/java/lang/System.html#nanoTime ()
• SO Frage zum Messen kleiner Zeitspannen, da System.nanoTime () auch einige Probleme hat: Wie kann ich Zeit in Java mit Mikrosekundengenauigkeit messen?

Stoppuhr ist eigentlich der beste Maßstab!

Die tatsächliche Antwortzeit des End-to-End-Benutzers ist die Zeit, die tatsächlich zählt.

Es ist nicht immer möglich, diese Zeit mit den verfügbaren Tools abzurufen. Beispielsweise enthalten die meisten Testtools nicht die Zeit, die ein Browser zum Rendern einer Seite benötigt, sodass auf einer überkomplexen Seite mit schlecht geschriebenem CSS Antwortzeiten von weniger als einer Sekunde für den Test angezeigt werden Tools, aber 5 Sekunden plus Antwortzeit an den Benutzer.

Die Tools eignen sich hervorragend für automatisierte Tests und zur Problembestimmung, verlieren jedoch nicht aus den Augen, was Sie wirklich messen möchten.

Ein Profiler bietet Ihnen detailliertere Informationen, mit denen Sie Leistungsprobleme diagnostizieren und beheben können.

In Bezug auf die tatsächliche Messung ist die Stoppuhrzeit das, was Benutzer bemerken. Wenn Sie also überprüfen möchten, ob die Dinge innerhalb akzeptabler Grenzen liegen, ist die Stoppuhrzeit in Ordnung.

Wenn Sie jedoch Probleme beheben möchten, kann ein Profiler sehr hilfreich sein.

Sie müssen eine realistische Anzahl von Iterationen testen, da Sie je nachdem, wie Sie das Timing testen, unterschiedliche Antworten erhalten. Wenn Sie eine Operation nur einmal ausführen, kann es irreführend sein, den Durchschnitt vieler Iterationen zu ermitteln. Wenn Sie wissen möchten, wie lange es nach dem Aufwärmen der JVM dauert, können Sie viele (z. B. 10.000) Iterationen ausführen, die nicht in den Timings enthalten sind.

Ich schlage auch vor, dass Sie verwenden, System.nanoTime()da es viel genauer ist. Wenn Ihre Testzeit etwa 10 Mikrosekunden oder weniger beträgt, möchten Sie dies nicht zu oft aufrufen, da dies Ihr Ergebnis ändern kann. (zB Wenn ich etwa 5 Sekunden lang teste und wissen möchte, wann dies aktiv ist, erhalte ich die nanoTime nur alle 1000 Iterationen, wenn ich weiß, dass eine Iteration sehr schnell ist.)

Wie gehen Sie beim Benchmarking mit der Betriebssystemplanung um?

Benchmarking lange genug auf einem System, das für die von Ihnen verwendete Maschine repräsentativ ist. Wenn Ihr Betriebssystem Ihre Anwendung verlangsamt, sollte dies Teil des Ergebnisses sein.

Es macht keinen Sinn zu sagen, mein Programm wäre schneller, wenn ich nur kein Betriebssystem hätte.

Wenn Sie verwenden Linux, können Sie Tools wie numactl, chrtund tasksetzu steuern , wie CPUs verwendet werden und die Terminplanung.

Profiler können sich dem Timing in den Weg stellen, daher würde ich eine Kombination aus Stoppuhr-Timing verwenden, um allgemeine Leistungsprobleme zu identifizieren, und dann den Profiler verwenden, um herauszufinden, wo die Zeit verbracht wird. Wiederholen Sie den Vorgang nach Bedarf.

Immerhin ist es wahrscheinlich die zweitbeliebteste Form des Benchmarking, gleich nach dem "No-Watch-Benchmarking" - wo wir sagen "diese Aktivität scheint langsam, diese scheint schnell zu sein."

In der Regel ist es am wichtigsten, zu optimieren, was die Benutzererfahrung beeinträchtigt. Dies hängt meistens davon ab, wie oft Sie die Aktion ausführen und was sonst noch gleichzeitig passiert. Andere Formen des Benchmarking helfen oft nur dabei, diese herauszufinden.

Ich denke, eine Schlüsselfrage ist die Komplexität und Dauer der Operation.

Manchmal verwende ich sogar physische Stoppuhrmessungen, um festzustellen, ob die Berechnung Minuten, Stunden, Tage oder sogar Wochen dauert (ich arbeite mit einer Anwendung, bei der Laufzeiten in der Größenordnung von mehreren Tagen nicht ungewöhnlich sind, selbst wenn Sekunden und Minuten vorhanden sind die häufigsten Zeitspannen).

Die Automatisierung, die durch Aufrufe eines beliebigen Uhrensystems auf dem Computer ermöglicht wird, wie der im verlinkten Artikel erwähnte Java-Millis-Aufruf, ist jedoch der manuellen Anzeige der Betriebsdauer deutlich überlegen.

Profiler sind nett, wenn sie funktionieren, aber ich hatte Probleme, sie auf unsere Anwendung anzuwenden, was normalerweise die dynamische Codegenerierung, das dynamische Laden von DLLs und die Arbeit in den beiden integrierten Just-in-Time-kompilierten Skriptsprachen von umfasst meine Bewerbung. Sie beschränken sich häufig darauf, eine einzige Ausgangssprache und andere unrealistische Erwartungen an komplexe Software anzunehmen.

Ich habe heute ein Programm ausgeführt, das Informationen aus einer Reihe von dBase-Dateien durchsucht und gesammelt hat. Die Ausführung dauerte etwas mehr als eine Stunde . Ich habe mir den Code angesehen, eine fundierte Vermutung über den Engpass angestellt, den Algorithmus geringfügig verbessert und das Programm erneut ausgeführt, diesmal in 2,5 Minuten .

Ich brauchte keine ausgefallenen Profiling-Tools oder Benchmark-Suiten, um zu erfahren, dass die neue Version eine signifikante Verbesserung darstellt. Wenn ich die Laufzeit weiter optimieren müsste, hätte ich wahrscheinlich eine komplexere Analyse durchgeführt, aber dies war nicht notwendig. Ich finde, dass diese Art des "Stoppuhr-Benchmarking" in einer Reihe von Fällen eine akzeptable Lösung ist und der Rückgriff auf fortschrittlichere Tools in diesen Fällen tatsächlich zeitaufwändiger wäre.

Ich denke nicht, dass Stoppuhr-Benchmarking zu schrecklich ist, aber wenn Sie auf einen Solaris- oder OS X-Computer zugreifen können, sollten Sie sich DTrace ansehen. Ich habe es verwendet, um einige großartige Informationen zum Timing in meinen Anwendungen zu erhalten.

Ich verwende immer Stoppuhr-Benchmarking, da es so viel einfacher ist. Die Ergebnisse müssen für mich allerdings nicht sehr genau sein. Wenn Sie genaue Ergebnisse benötigen, sollten Sie kein Stoppuhr-Benchmarking verwenden.

Das mache ich die ganze Zeit. Ich würde viel lieber einen Profiler verwenden, aber der Anbieter der domänenspezifischen Sprache, mit der ich arbeite, bietet keinen an.