Sergio
8a0496dbb3
Medida la ganancia del PGO ayer: -9,4% en una página de DOM/maquetación y -1,0% en 3d-raytrace de SunSpider. La razón de la diferencia es que un benchmark JIT-bound es casi CIEGO al PGO: el bucle caliente no lo ejecuta el C++ de SpiderMonkey sino el código máquina que el JIT emite en runtime, y el PGO optimiza el intérprete, el GC y el propio JIT — no lo que el JIT produce. El corpus de Mozilla está dominado en número de páginas por SunSpider, o sea que entrenaba mucho justo donde el PGO menos rinde. Estas diez ejercitan el camino que sí es C++ de punta a punta: flex flexbox anidado, wrap, alineaciones rejilla CSS Grid: pistas, áreas nombradas, auto-fit tablas tablas grandes con table-layout FIJO y AUTO (dos algoritmos) texto columnas, shaping, reflujo por cambio de ancho selectores DOM profundo contra 600 reglas, muchas que NO casan pintado degradados, sombras, opacidad, mix-blend-mode transformar transforms y contextos de apilamiento svg paths, degradados, clip desbordes overflow anidado, position:sticky, scroll programático reflujo layout thrashing: leer y escribir geometría alternadamente Reglas que cumplen todas, y no son de estilo: · DETERMINISTAS (LCG propio, ni Math.random ni Date ni red) — dos corridas hacen lo mismo, así que dos perfiles difieren por el timing de los contadores y no por haber visitado caminos distintos. · AUTOCONTENIDAS — el perfilado corre sin red. · NUESTRAS — nada de páginas ajenas capturadas, que traerían licencia y fragilidad. · ACOTADAS — 16 a 32 s cada una; el perfilado arranca un navegador POR PÁGINA. Validadas las diez contra el firefox sellado: todas renderizan y producen captura. `flex` hubo que acortarla de 40 a 12 cajas raíz: con 40 la página medía 68.241 px de alto y la captura moría con «Failed to allocate a surface due to invalid size». El layout ocurría igual, pero sin captura no se ejercita el pintado, que es justo la mitad que se venía a entrenar.
Corpus de maquetación para el PGO de Gecko
Páginas de entrenamiento nuestras que complementan el corpus de Mozilla (build/pgo).
Por qué existe
Medida la ganancia del PGO el 2026-09-07 (SDD 26 §3.a): −9,4 % en una página de DOM/maquetación
y −1,0 % en 3d-raytrace de SunSpider. El corpus de Mozilla está dominado en número de páginas
por SunSpider, que es aritmética pura en bucles calientes — y ese bucle no lo ejecuta el C++ de
SpiderMonkey sino el código máquina que el JIT emite en runtime, que el PGO no toca. O sea que el
corpus entrenaba mucho justo donde el PGO menos rinde.
Estas páginas ejercitan el camino que sí es C++ de punta a punta: resolución de estilo, layout, pintado y composición.
Reglas que cumplen todas, y por qué
- Deterministas. Ni
Math.randomniDateni red. Dos corridas hacen LO MISMO, así que dos perfiles difieren por el timing de los contadores y no por haber visitado caminos distintos. - Autocontenidas. CSS y JS en línea, sin recursos externos. El perfilado corre sin red.
- Nuestras. Escritas para esto: nada de páginas ajenas capturadas, que traerían licencia y fragilidad.
- Acotadas. Cada una termina en segundos. El perfilado arranca un navegador POR PÁGINA.
Qué ejercita cada una
| página | subsistema |
|---|---|
flex.html |
flexbox anidado, wrap, alineaciones, min/max-content |
rejilla.html |
CSS Grid: muchas pistas, áreas nombradas, auto-fit, subgrid |
tablas.html |
tablas grandes, colspan/rowspan, table-layout fijo y automático |
texto.html |
texto largo, columnas, text-shadow, tamaños y pesos variados, reflujo |
selectores.html |
resolución de estilo: DOM profundo contra cientos de reglas |
pintado.html |
degradados, border-radius, box-shadow, opacity, mix-blend-mode |
transformar.html |
transform, contextos de apilamiento, will-change |
svg.html |
SVG en línea: paths, degradados, use, clip |
desbordes.html |
overflow anidado, position: sticky, scroll programático |
reflujo.html |
layout thrashing: leer y escribir geometría alternadamente |