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.
28 lines
1.2 KiB
HTML
28 lines
1.2 KiB
HTML
<!doctype html><meta charset=utf-8><title>desbordes</title><style>
|
|
body{margin:0;font:12px sans-serif}
|
|
.sc{overflow:auto;border:1px solid #ccb;margin:3px;height:170px}
|
|
.sk{position:sticky;top:0;background:#ffe;border-bottom:1px solid #dd9;padding:2px}
|
|
.it{padding:2px 4px;border-bottom:1px dotted #ddd}
|
|
</style><div id=r></div><script>
|
|
function lcg(x){return function(){x=(x*1103515245+12345)&0x7fffffff;return x/0x7fffffff}}
|
|
var r=lcg(83), h=[];
|
|
// Contenedores de scroll anidados con `position:sticky`: Gecko tiene que recalcular la posición
|
|
// pegajosa en cada scroll, y eso es camino de layout puro.
|
|
for(var c=0;c<26;c++){
|
|
h.push("<div class=sc id=s"+c+"><div class=sk>cabecera pegajosa "+c+"</div>");
|
|
for(var i=0;i<160;i++){
|
|
if(i%40===0) h.push("<div class=sc style='height:90px'><div class=sk>anidada</div>");
|
|
h.push("<div class=it>"+((r()*1e9)|0).toString(36)+" — fila "+i+"</div>");
|
|
if(i%40===39) h.push("</div>");
|
|
}
|
|
h.push("</div>");
|
|
}
|
|
document.getElementById('r').innerHTML=h.join("");
|
|
// Scroll programático: fuerza recálculo de sticky y de lo visible.
|
|
var t=0;
|
|
for(var i=0;i<60;i++){
|
|
for(var c=0;c<26;c++){ var n=document.getElementById('s'+c); if(n){ n.scrollTop=(i*37)%900; t+=n.scrollTop; } }
|
|
}
|
|
document.title="desb-"+(t|0);
|
|
</script>
|