Comparar el mínimo de ejecuciones repetidas detecta regresiones de rendimiento en runners de CI compartidos con menos falsas alarmas que comparar las medias

Hipótesis

La documentación de timeit de Python recomienda tomar el mínimo de las mediciones repetidas como probablemente el único valor de interés, porque los valores más altos se deben a la interferencia de otros procesos y no a la variabilidad del código. La hipótesis extiende este criterio a las comprobaciones automáticas de regresión en runners de integración continua compartidos, donde la interferencia es mayor e impredecible: en microbenchmarks limitados por CPU, una comprobación que compara el mínimo de N ejecuciones del commit candidato con el mínimo de N ejecuciones del commit base, con un umbral relativo fijo, produce menos falsas alarmas sobre código sin cambios y deja pasar menos ralentizaciones inyectadas que la misma comprobación aplicada a la media o a la mediana. El razonamiento es que, en una máquina compartida, la interferencia solo puede añadir tiempo; por eso el mínimo estima una ejecución libre de interferencia, mientras que la media arrastra el ruido. Se predice que la ventaja desaparece o se invierte en benchmarks limitados por E/S, donde el mínimo refleja una cache caliente y no el código.

Predicción

Al repetir muchas veces la CI sobre el mismo commit, el mínimo variará menos entre ejecuciones que la media. Si se inyectan en el código ralentizaciones de un pequeño porcentaje, la comprobación basada en el mínimo las detectará con un umbral en el que la comprobación basada en la media o bien no las detecta o bien, con un umbral más bajo, marca commits sin cambios. La detección estadística de valores atípicos de hyperfine señalará ejecuciones en CI con más frecuencia que en una máquina tranquila, lo cual cuantifica el ruido del que trata la hipótesis.

Prueba propuesta

1. Seleccionar un conjunto de benchmarks: varios limitados por CPU (parseo, hashing, ordenación), varios con uso intensivo de asignación de memoria y varios limitados por E/S.
2. Crear variantes con ralentizaciones conocidas de aproximadamente el 3 %, el 10 % y el 30 % mediante trabajo adicional proporcional, y conservar la versión sin cambios como control.
3. Ejecutar cada variante en runners de CI compartidos muchas veces al día durante al menos dos semanas, con N repeticiones por ejecución y orden intercalado, registrando todas las mediciones individuales.
4. Para cada estadístico (mínimo, mediana, media, media truncada) y cada umbral, contar las falsas alarmas en el control y las detecciones fallidas en las variantes ralentizadas.
5. Comparar las curvas de detección frente a falsas alarmas por clase de benchmark e informar de la variabilidad entre ejecuciones de cada estadístico.

Estado

No se afirma ningún resultado. Posibles factores de confusión: el escalado de frecuencia de la CPU y el hardware heterogéneo de los runners hacen bimodal incluso el mínimo; un N pequeño vuelve ruidoso al propio mínimo; y los benchmarks con efectos de calentamiento pueden hacer que el mínimo represente un estado que el código de producción nunca alcanza.