Comparer le minimum d'exécutions répétées signale les régressions de performance sur des exécuteurs CI partagés avec moins de fausses alertes que la comparaison des moyennes

Hypothèse

La documentation Python de timeit conseille que le minimum des mesures répétées est probablement le seul nombre digne d'intérêt, car les valeurs plus élevées proviennent d'interférences d'autres processus plutôt que de la variabilité du code. Cette hypothèse étend ce principe aux vérifications automatisées de régression sur des exécuteurs d'intégration continue partagés, où les interférences sont plus fortes et imprévisibles : pour les micro-benchmarks liés au CPU, une vérification qui compare le minimum de N exécutions sur le commit candidat avec le minimum de N exécutions sur le commit de référence, à l'aide d'un seuil relatif fixe, produit moins de fausses alertes sur du code inchangé et manque moins de ralentissements injectés que la même vérification appliquée à la moyenne ou à la médiane. Le raisonnement est que les interférences sur une machine partagée ne font qu'ajouter du temps, jamais en retrancher, de sorte que le minimum estime une exécution sans interférence tandis que la moyenne porte le bruit. Cet avantage devrait disparaître, voire s'inverser, pour les benchmarks liés aux entrées/sorties, où le minimum reflète un cache chaud plutôt que le code.

Prédiction

Sur de nombreuses exécutions CI d'un même commit, le minimum variera moins d'une exécution à l'autre que la moyenne. Avec des ralentissements de quelques pour cent injectés dans le code, la vérification fondée sur le minimum les détectera à un seuil où la vérification fondée sur la moyenne les manque, ou, à un seuil plus bas, signale des commits inchangés. La détection d'anomalies statistiques de hyperfine signalera des exécutions sur CI plus souvent que sur une machine calme, ce qui quantifie le bruit dont traite l'hypothèse.

Test proposé

1. Sélectionner un ensemble de benchmarks : plusieurs liés au CPU (analyse syntaxique, hachage, tri), plusieurs intensifs en allocation et plusieurs liés aux entrées/sorties.
2. Créer des variantes avec des ralentissements connus d'environ 3 %, 10 % et 30 % en ajoutant un travail supplémentaire proportionnel, et conserver la version inchangée comme témoin.
3. Exécuter chaque variante sur des exécuteurs CI partagés plusieurs fois par jour pendant au moins deux semaines, avec N répétitions par exécution et un ordre entrelacé, en enregistrant toutes les mesures individuelles.
4. Pour chaque statistique (minimum, médiane, moyenne, moyenne tronquée) et chaque seuil, compter les fausses alertes sur le témoin et les ralentissements manqués sur les variantes ralenties.
5. Comparer les courbes de détection en fonction des fausses alertes par catégorie de benchmark et rendre compte de la variabilité d'une exécution à l'autre pour chaque statistique.

Statut

Aucun résultat n'est revendiqué. Facteurs de confusion possibles : la mise à l'échelle de la fréquence du CPU et un matériel d'exécuteur hétérogène rendent même le minimum bimodal ; un N faible rend le minimum lui-même bruité ; les benchmarks avec des effets de préchauffage peuvent faire en sorte que le minimum représente un état que le code de production n'atteint jamais.