¿Cómo afectan los diversos proyectos de optimización de Javascript al rendimiento de DOM?

Question

Hay mucha informática con C mayúscula y S mayúscula en Javascript a través de los proyectos Tracemonkey, Squirrelfish y V8.¿Alguno de estos proyectos (u otros) aborda el desempeño de las operaciones DOM, o están puramente relacionados con el cálculo de Javascript?

Answer 1

El rendimiento de las operaciones DOM puras (getElementById/Tagname/Selector, nextChild, etc.) no se ve afectado porque ya están en C++ puro.

La forma en que las mejoras del motor JS afectarán el rendimiento depende hasta cierto punto de las técnicas particulares utilizadas para las mejoras de rendimiento, así como del rendimiento del puente DOM->JS.

Un ejemplo de lo primero es la dependencia de TraceMonkey de que todas las llamadas sean a funciones JS.Debido a que un seguimiento alinea efectivamente la ruta de ejecución en cualquier punto donde JS llega a código que no se puede incluir (código nativo, recursividad polimórfica verdadera, controladores de excepciones), el seguimiento se cancela y la ejecución vuelve al intérprete.Los desarrolladores de TM están trabajando bastante para mejorar la cantidad de código que se puede rastrear (incluido el manejo de la recursividad polimórfica), pero de manera realista, rastreando llamadas a funciones nativas arbitrarias (p. ej.el DOM) no es factible.Por esa razón, creo que están considerando implementar más DOM en JS (o al menos de una manera compatible con JS).Dicho esto, cuando el código es rastreable, la MT puede hacer un trabajo excepcionalmente bueno, ya que puede reducir la mayoría de los "objetos" a equivalentes más eficientes y/o nativos (por ejemplo,utilice ints de máquina en lugar de la implementación del número JS).

JavaScriptCore (que es donde vive SquirrelFish Extreme) y V8 tienen un enfoque más similar en el sentido de que ambos JIT todo el código JS inmediatamente y producen código que es más especulativo (por ejemplo,si lo estas haciendo a*b generan código que asume a y b son números y recurre a un código excepcionalmente lento si no lo son).Esto tiene una serie de beneficios sobre el rastreo, a saber, que puede ejecutar todo el código, independientemente de si llama o no al código nativo/arroja excepciones, etc., lo que significa que una sola llamada DOM no destruirá el rendimiento.La desventaja es que todo el código es especulativo - TM voluntad llamadas en línea a Math.floor, etc., pero lo mejor que JSC/V8 puede hacer sería equivalente a a=Math.floor(0.5) -> a=(Math.floor == realFloor) ? inline : Math.floor(0.5) Esto tiene costos tanto en rendimiento como en uso de memoria, y tampoco es particularmente factible.La razón de esto es la compilación inicial, mientras que TM solo ejecuta el código JIT después de ejecutarlo (y por lo tanto sabe exactamente qué función se llamó), JSC y V8 no tienen una base real para hacer tal suposición y básicamente tienen que adivinar (y actualmente ninguno intenta). este).Lo único que hacen V8 y JSC para intentar compensar este problema es realizar un seguimiento de lo que han visto en el pasado e incorporarlo en la ruta de ejecución. Ambos utilizan una combinación de técnicas para realizar este almacenamiento en caché, en casos especialmente difíciles. reescriben pequeñas porciones del flujo de instrucciones y, en otros casos, se mantienen fuera de los cachés de banda.En términos generales, si tienes un código que vaya

a.x * a.y

V8 y JSC verificarán el 'tipo implícito'/'Estructura' dos veces, una para cada acceso, y luego verificarán que a.x y a.y son ambos números, mientras que TM generará un código que verifica el tipo de a sólo una vez, y puede (en igualdad de condiciones) simplemente multiplicar a.x y a.y sin comprobar que son números.

Si nos fijamos en la velocidad de ejecución pura, actualmente hay una especie de mezcla, ya que cada motor parece funcionar mejor en ciertas tareas que en otras: TraceMonkey gana en muchas pruebas de matemáticas puras, V8 gana en casos muy dinámicos, JSC gana si hay una mezcla.Por supuesto, si bien eso es cierto hoy, puede que no lo sea mañana, ya que todos estamos trabajando duro para mejorar el rendimiento.

El otro problema que mencioné fue el costo de enlace DOM<->JS; esto en realidad puede desempeñar un papel muy importante en el rendimiento web; el mejor ejemplo de esto es Safari 3.1/2 vs Chrome en el punto de referencia Dromaeo.Chrome se basa en la rama Safari 3.1/2 de WebKit, por lo que es razonablemente seguro asumir un rendimiento DOM similar (la diferencia del compilador podría causar cierto grado de variación).En este punto de referencia, Safari 3.1/2 en realidad supera a Chrome a pesar de tener un motor JS que es claramente mucho más lento, esto se debe básicamente a enlaces más eficientes entre JSC/WebCore (el dom/rendering/etc de WebKit) y V8/WebCore.

Actualmente, mirar los enlaces DOM de TM parece injusto ya que no han completado todo el trabajo que quieren hacer (por desgracia), por lo que simplemente recurren al intérprete :-(

..

Errmmm, eso duró un poco más de lo previsto, por lo que la respuesta breve a la pregunta original es "depende": D

Answer 2

Son JavaScript puro. A menos que se implemente una llamada de método DOM particular en JS, tendrán poco efecto (sin decir que no se ha trabajado para reducir la sobrecarga de tales llamadas )

La optimización del DOM es una gran variedad de ardillas monos arañas peces ... El diseño e incluso los motores de renderizado entran en juego, y cada navegador tiene su propia estrategia de implementación y optimización.