Comment les différents projets d'optimisation Javascript affectent-ils les performances du DOM?

Question

Il y a beaucoup de C, C et C d'informatique qui entrent dans Javascript via les projets Tracemonkey, Squirrelfish et V8. Certains de ces projets (ou d’autres) traitent-ils des performances des opérations DOM ou sont-ils purement liés au calcul Javascript?

Answer 1

Les performances des opérations DOM pures (getElementById / Tagname / Selector, nextChild, etc.) ne sont pas affectées, car elles sont déjà en C ++ pur.

La manière dont les améliorations du moteur JS affecteront les performances dépendra dans une certaine mesure des techniques particulières utilisées pour les améliorations des performances, ainsi que des performances du pont DOM - > JS.

Un exemple du premier est la dépendance de TraceMonkey à l’égard de tous les appels aux fonctions JS. Puisqu'une trace insère effectivement dans le chemin d'exécution tout point où le JS rencontre un code qui ne peut pas être inséré (code natif, vraie récursion polymorphe, gestionnaires d'exceptions), la trace est abandonnée et l'exécution revient à l'interpréteur. Les développeurs de MT font beaucoup de travail pour améliorer la quantité de code qui peut être suivi (y compris la gestion de la récursion polymorphe). Cependant, il n'est pas réaliste de retracer de manière réaliste les appels à des fonctions natives arbitraires (par exemple, le DOM). Pour cette raison, je pense qu'ils envisagent de mettre en œuvre davantage de DOM dans JS (ou au moins de manière conviviale pour JS). Cela dit, lorsque le code est traçable, TM peut faire un travail exceptionnellement bon puisqu'il peut réduire la plupart des & Objets & "; vers des équivalents plus efficaces et / ou natifs (par exemple, utilisez une machine ints au lieu de l’implémentation JS Number).

JavaScriptCore (où réside SquirrelFish Extreme) et la V8 ont une approche plus similaire en ce sens qu’ils JIT tout le code JS immédiatement et produisent un code plus spéculatif (par exemple, si vous faites a*b ils génèrent du code qui suppose a et b sont des nombres et utilisent un code exceptionnellement lent s'ils ne le sont pas). Cela présente un certain nombre d'avantages par rapport au traçage, à savoir que vous pouvez copier tout le code, qu'il appelle ou non du code natif / lève des exceptions, etc., ce qui signifie qu'un seul appel DOM ne détruira pas les performances. L'inconvénient est que tout le code est spéculatif - TM lancera des appels en ligne vers Math.floor, etc., mais que le meilleur que JSC / V8 puisse faire équivaudrait à a=Math.floor(0.5) - & Gt; a=(Math.floor == realFloor) ? inline : Math.floor(0.5) Cela a des coûts en termes de performances et d’utilisation de la mémoire, ce n’est pas non plus particulièrement faisable. La raison en est la compilation initiale, alors que TM ne gère que le code JIT après son exécution (et sait donc exactement quelle fonction a été appelée) JSC et V8 n’ont aucune base réelle pour émettre une telle hypothèse et doivent en principe deviner (et actuellement aucune tentative ce). La seule chose que V8 et JSC font pour tenter de remédier à ce problème est de suivre ce qu’ils ont vu dans le passé et de l’intégrer au chemin d’exécution. Ils utilisent une combinaison de techniques pour effectuer cette mise en cache, notamment dans les cas les plus critiques. ils réécrivent de petites parties du flux d'instructions et, dans d'autres cas, ils ne sont pas en cache. En gros, si vous avez du code qui va

a.x * a.y

V8 et JSC vérifieront le "type implicite" / "Structure" deux fois - une fois pour chaque accès, puis vérifieront que a.x et a.y sont tous deux des nombres, tandis que TM générera un code vérifiant le type de <=> une seule fois, et peut (toutes choses égales par ailleurs) simplement multiplier <=> et <=> sans vérifier que ce sont des nombres.

Si vous envisagez la vitesse d'exécution pure, vous constaterez qu'il y a un mélange de choses. Chaque moteur semble mieux réussir certaines tâches que d'autres. TraceMonkey gagne de nombreux tests en mathématiques pures, la V8 l'emporte dans les cas très dynamiques, JSC gagne s'il y a un mélange. Bien sûr, même si cela est vrai aujourd’hui, il se peut que ce ne soit pas demain, car nous travaillons tous très fort pour améliorer les performances.

L’autre problème que j’ai mentionné est le DOM < - > le coût de la liaison JS - il peut en réalité jouer un rôle très important dans les performances Web, le meilleur exemple étant Safari 3.1 / 2 vs Chrome à la référence Dromaeo. Chrome étant basé sur la branche Safari 3.1 / 2 de WebKit, il est donc raisonnablement prudent de supposer des performances DOM similaires (les différences entre les compilateurs peuvent entraîner une certaine variance). Dans cette référence, Safari 3.1 / 2 bat effectivement Chrome, malgré uneMoteur JS qui est nettement beaucoup plus lent, ceci est essentiellement dû à des liaisons plus efficaces entre JSC / WebCore (le dom / rendering / etc de WebKit) et le V8 / WebCore

Examiner actuellement les liaisons DOM de TM semble injuste car ils n’ont pas terminé tout le travail qu’ils souhaitent (hélas), ils se contentent donc de l’interprète: - (

..

Errmmm, cela a duré un peu plus longtemps que prévu, donc réponse courte à la question initiale est & "ça dépend &"; : D

Answer 2

Ils sont purement JavaScript. À moins qu'un appel de méthode DOM particulier ne soit implémenté dans JS, ils n'auront que peu d'effet (pour ne pas dire que rien n'a été fait pour réduire le temps système de tels appels). ).

L’optimisation DOM est un véritable «panier d’écureuils singes araignées ... La disposition et même les moteurs de rendu entrent en jeu, et chaque navigateur a sa propre stratégie d'implémentation et d'optimisation.