Méthodologie de benchmark : échauffer, alterner les répétitions, rapporter la dispersion

Objectif

Produire une comparaison de temps entre deux versions d'une fonction, d'une requête ou d'une commande, qu'une autre personne puisse reproduire, et qui ne présente pas du bruit comme une amélioration.

Prérequis

Une machine sur laquelle rien d'autre ne tourne (portable sur secteur avec un profil énergétique fixe, ou un hôte dédié) ; les entrées exactes ; les versions de l'interpréteur ou du compilateur ; une décision sur ce qui est mesuré : le temps réel d'une commande entière ou un micro-benchmark d'une fonction.

Étapes

1. Fixer la charge de travail avant toute exécution : mêmes données, mêmes tailles et mêmes paramètres, figés dans le script de benchmark.
2. Échauffer puis écarter : les premières exécutions ne comptent pas, afin que les caches de fichiers, le compilateur JIT et l'initialisation différée ne soient pas imputés à une seule variante. hyperfine propose pour cela --warmup N ; pour la question inverse (cache froid), --prepare avec une commande qui vide le cache avant chaque exécution.
3. Répéter en alternance : A, B, A, B plutôt que d'abord tous les A, puis tous les B, afin qu'une dérive de la machine (limitation thermique, une tâche de fond) touche les deux variantes de la même façon.
4. Définir l'indicateur à l'avance. La documentation du module timeit de Python indique que, dans le cas typique, la valeur la plus basse constitue une borne inférieure de la vitesse à laquelle la machine peut exécuter l'extrait, et que les valeurs plus élevées proviennent le plus souvent d'autres processus — elle déconseille donc de rapporter la moyenne et l'écart type. Pour le débit de systèmes complets avec entrées-sorties, la médiane et les percentiles décrivent ce que vivent les personnes utilisatrices.
5. Consigner la dispersion : nombre d'exécutions ainsi que minimum, médiane et maximum par variante. hyperfine effectue une détection statistique des valeurs aberrantes, qui signale des perturbations dues à d'autres programmes et à des effets de cache ; une exécution signalée est une raison de recommencer, non une donnée à écarter silencieusement.
6. Noter l'environnement : modèle de processeur, mise à l'échelle de fréquence, limites CPU dans le conteneur, version du langage, et si le ramasse-miettes était désactivé (timeit le désactive par défaut pendant la mesure).
7. Rapporter : les chiffres, la commande exacte, l'environnement et la règle de comparaison. Un écart plus petit que la dispersion entre exécutions n'est pas un résultat ; un écart de quelques pour cent nécessite un très grand nombre d'exécutions pour devenir seulement visible.

Résultat attendu

Un tableau avec N exécutions, minimum, médiane et maximum ainsi que l'environnement par variante, accompagné du script — une personne lectrice peut l'exécuter et obtient un résultat compris dans la dispersion rapportée.

Limites et base de vérification

Un micro-benchmark mesure une fonction isolément ; l'effet dans le programme réel peut être plus faible (la fonction n'est pas sollicitée intensément) ou plus fort (effets de cache et d'allocation). Les exécuteurs CI partagés ajoutent un bruit qu'aucune statistique n'élimine ; savoir si le minimum y est l'indicateur le plus robuste fait l'objet d'une hypothèse distincte dans le wiki. La démarche s'appuie sur la documentation citée ; aucune valeur de mesure n'est affirmée ici.