Files
takana/scripts/diagnostico
SergioandClaude Opus 5 8ff6ae7b3a pgo: el control que faltaba — el arranque eran 16 s y diluía todos los porcentajes
El banco medía el ciclo COMPLETO del proceso (arrancar → renderizar → capturar → salir)
y nunca se midió cuánto de eso era arranque. Con una página vacía como control, y las 4
cargas × 2 variantes en UNA sola sesión intercalada (restar entre corridas de días
distintos no vale: la misma variante deriva ~1%):

  maquetación   trabajo 7281 → 4744 ms   -34,8%   (publicado: -10,9%)
  carga ajena   trabajo 4550 → 4634 ms    +1,8%   = cero, y es buena señal
  SunSpider     trabajo  -34 →   -6 ms   bajo el ruido

Dos correcciones al documento:

1. El -10,9% es correcto para el ciclo completo pero se leía como 'firefox 11% más
   rápido'. Sobre el trabajo de la página el PGO rinde -34,8%: tres veces más. El error
   subestimaba el propio resultado.

2. La explicación que di del SunSpider era aire. Su trabajo mide -34 ms, NEGATIVO: la
   página con el benchmark tardó menos que la vacía. No había nada que medir, y yo le
   colgué encima una teoría sobre el JIT. La teoría puede ser cierta; esta medición
   nunca la probó.

Las tablas viejas se dejan sin retocar, con un aviso arriba: el error de método enseña
más que el número corregido. Todo el rigor estadístico estaba puesto sobre una cantidad
que no era la que yo creía medir, y ninguna repetición lo habría revelado — sólo un
control, que costó siete corridas de una página vacía.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_014QPJteswQvP1L7zSBrQQe2
2026-09-08 14:57:26 +00:00
..