Benchmarking en sistemas modernos rara vez produce datos limpios y comparables. Aunque el software bajo prueba sea determinista, el resto del entorno —sistema operativo, hardware, JVM, mecanismos de seguridad— introduce variaciones que pueden cambiar los tiempos de ejecución entre iteraciones y entre ejecuciones. Este artículo, basado en una conferencia sobre benchmarking, utiliza resultados ficticios de un programa de nóminas en Java sobre Linux para mostrar cómo cambian los tiempos sin modificar el código: una segunda ejecución aparece más rápida desde la tercera iteración, una tercera ejecución es más lenta hasta la iteración 14 y luego cambia otra vez dentro del mismo proceso.
Las causas posibles son múltiples: el sistema operativo puede reasignar memoria física, mover el proceso a otro tipo de núcleo, activar thermal throttling o cambiar la frecuencia de reloj; el compilador JIT de la JVM puede tomar decisiones de optimización distintas según la información de perfilado; el recolector de basura puede intervenir de forma no uniforme; y mecanismos como la liberación de clases internas de la JVM o la aleatorización del espacio de direcciones también alteran las mediciones. Factores ambientales (temperatura, alimentación del portátil, actualizaciones) suman más variabilidad.
El autor concluye que no existe una receta única. Algunas variables se pueden controlar (fijar núcleos, desactivar ASLR, fijar frecuencias) a costa de parecer poco realistas; otras exigen más repeticiones para caracterizar la distribución; y otras obligan a repetir el experimento. La pregunta clave antes de comparar datos es siempre la misma: ¿estamos seguros de que las condiciones son comparables? El texto incluye una lista de categorías a vigilar: optimizaciones en tiempo de ejecución, mecanismos de seguridad, complejidad del hardware e impacto ambiental.