Comparar o mínimo de execuções repetidas detecta regressões de benchmark em runners de CI compartilhados com menos alarmes falsos do que comparar médias

Hipótese

A documentação do timeit do Python recomenda que o mínimo das medições repetidas é provavelmente o único número de interesse, porque os valores mais altos vêm da interferência de outros processos, e não de variabilidade do código. A hipótese estende essa ideia a verificações automáticas de regressão em runners compartilhados de integração contínua, onde a interferência é maior e imprevisível: para microbenchmarks limitados por CPU, uma verificação que compara o mínimo de N execuções no commit candidato com o mínimo de N execuções no commit base, usando um limite relativo fixo, produz menos alarmes falsos em código inalterado e deixa passar menos lentidões injetadas do que a mesma verificação aplicada à média ou à mediana. O raciocínio é que, numa máquina compartilhada, a interferência sempre apenas acrescenta tempo; assim, o mínimo estima uma execução sem interferência, enquanto a média carrega o ruído. Prevê-se que a vantagem desapareça ou se inverta em benchmarks limitados por I/O, nos quais o mínimo reflete um cache aquecido, e não o código.

Previsão

Em muitas execuções de CI do mesmo commit, o mínimo variará menos entre execuções do que a média. Com lentidões de alguns por cento injetadas no código, a verificação baseada no mínimo as detectará num limite em que a verificação baseada na média ou as deixa passar ou, com um limite mais baixo, sinaliza commits inalterados. A detecção estatística de outliers do hyperfine sinalizará execuções no CI com mais frequência do que numa máquina sem carga, o que quantifica o ruído de que trata a hipótese.

Teste proposto

1. Selecionar um conjunto de benchmarks: vários limitados por CPU (parsing, hashing, ordenação), vários intensivos em alocação e vários limitados por I/O.
2. Criar variantes com lentidões conhecidas de cerca de 3%, 10% e 30%, adicionando trabalho extra proporcional, e manter a versão inalterada como controle.
3. Executar cada variante em runners de CI compartilhados muitas vezes por dia, durante pelo menos duas semanas, com N repetições por execução e ordem intercalada, registrando todas as medições individuais.
4. Para cada estatística (mínimo, mediana, média, média aparada) e cada limite, contar os alarmes falsos no controle e as lentidões não detectadas nas variantes lentas.
5. Comparar as curvas de detecção versus alarmes falsos por classe de benchmark e relatar a variabilidade entre execuções de cada estatística.

Estado

Nenhum resultado é afirmado. Possíveis fatores de confusão: o escalonamento de frequência da CPU e o hardware heterogêneo dos runners tornam até o mínimo bimodal; um N pequeno torna o próprio mínimo ruidoso; benchmarks com efeitos de aquecimento (warm-up) podem fazer o mínimo representar um estado que o código de produção nunca alcança.