Der Vergleich des Minimums wiederholter Läufe erkennt Benchmark-Regressionen auf gemeinsam genutzten CI-Runnern mit weniger Fehlalarmen als der Vergleich von Mittelwerten

Hypothese

Die Dokumentation zu Pythons timeit rät, dass das Minimum der wiederholten Zeitmessungen wahrscheinlich die einzig interessante Zahl ist, da höhere Werte eher von störenden anderen Prozessen stammen als von Schwankungen im Code. Die Hypothese überträgt dies auf automatisierte Regressionsprüfungen auf gemeinsam genutzten Continuous-Integration-Runnern, wo Störungen stärker und unvorhersehbarer sind: Bei CPU-gebundenen Mikrobenchmarks erzeugt eine Prüfung, die das Minimum von N Läufen beim Kandidaten-Commit mit dem Minimum von N Läufen beim Basis-Commit anhand eines festen relativen Schwellenwerts vergleicht, weniger Fehlalarme bei unverändertem Code und übersieht weniger eingefügte Verlangsamungen als dieselbe Prüfung, angewendet auf den Mittelwert oder den Median. Die Begründung lautet, dass Störungen auf einer gemeinsam genutzten Maschine stets nur Zeit hinzufügen, sodass das Minimum einen störungsfreien Lauf schätzt, während der Mittelwert das Rauschen mitträgt. Es wird erwartet, dass dieser Vorteil bei I/O-gebundenen Benchmarks verschwindet oder sich umkehrt, wo das Minimum eher einen warmen Cache als den Code widerspiegelt.

Vorhersage

Über viele CI-Läufe desselben Commits hinweg wird das Minimum weniger zwischen Läufen schwanken als der Mittelwert. Bei Verlangsamungen von wenigen Prozent, die in den Code eingefügt werden, wird die auf dem Minimum basierende Prüfung diese bei einem Schwellenwert erkennen, bei dem die auf dem Mittelwert basierende Prüfung sie entweder übersieht oder, bei einem niedrigeren Schwellenwert, unveränderte Commits fälschlich meldet. Die statistische Ausreissererkennung von hyperfine wird Läufe auf CI häufiger melden als auf einer ruhigen Maschine, was das Rauschen quantifiziert, um das es in der Hypothese geht.

Vorgeschlagener Test

1. Eine Reihe von Benchmarks auswählen: mehrere CPU-gebundene (Parsen, Hashing, Sortieren), mehrere allokationsintensive und mehrere I/O-gebundene.
2. Varianten mit bekannten Verlangsamungen von etwa 3 %, 10 % und 30 % erzeugen, indem proportionale zusätzliche Arbeit hinzugefügt wird, und die unveränderte Version als Kontrolle behalten.
3. Jede Variante über mindestens zwei Wochen hinweg mehrmals täglich auf gemeinsam genutzten CI-Runnern ausführen, mit N Wiederholungen pro Lauf und verschachtelter Reihenfolge, wobei alle einzelnen Zeitmessungen aufgezeichnet werden.
4. Für jede Kennzahl (Minimum, Median, Mittelwert, getrimmter Mittelwert) und jeden Schwellenwert die Fehlalarme bei der Kontrolle und die verpassten Erkennungen bei den verlangsamten Varianten zählen.
5. Die Kurven von Erkennung gegenüber Fehlalarmen pro Benchmark-Klasse vergleichen und die Lauf-zu-Lauf-Variabilität jeder Kennzahl berichten.

Status

Es wird kein Ergebnis behauptet. Mögliche Störfaktoren: CPU-Frequenzskalierung und heterogene Runner-Hardware machen selbst das Minimum bimodal; ein kleines N macht das Minimum selbst verrauscht; Benchmarks mit Aufwärmeffekten können dazu führen, dass das Minimum einen Zustand darstellt, den der Produktionscode nie erreicht.