154 votes

Les navigateurs analysent-ils le javascript à chaque chargement de page ?

Les navigateurs (IE et Firefox) analysent-ils les fichiers javascript liés chaque fois que la page est actualisée ?

Ils peuvent mettre les fichiers en cache, donc je suppose qu'ils n'essaieront pas de les télécharger à chaque fois, mais comme chaque page est essentiellement séparée, je m'attends à ce qu'ils démontent tout ancien code et le ré-analysent.

C'est inefficace, bien que parfaitement compréhensible, mais je me demande si les navigateurs modernes sont suffisamment intelligents pour éviter l'étape d'analyse syntaxique dans les sites. Je pense aux cas où un site utilise une bibliothèque javascript, comme ExtJS ou jQuery, etc.

273voto

Jivings Points 10892

Ce sont les détails que j'ai pu déterrer. Il faut d'abord noter que, bien que JavaScript soit généralement considéré comme étant interprété et exécuté sur une machine virtuelle, ce n'est pas vraiment le cas avec les interpréteurs modernes, qui ont tendance à compiler la source directement en code machine (à l'exception d'IE).


Chrome : Moteur V8

V8 dispose d'un cache de compilation. Il stocke le JavaScript compilé en utilisant un hachage de la source pour un maximum de 5 collectes de déchets. Cela signifie que deux morceaux identiques de code source partageront une entrée de cache en mémoire, quelle que soit la manière dont ils ont été inclus. Ce cache n'est pas effacé lorsque les pages sont rechargées.

Source :


Opéra : Carakan Engine

En pratique, cela signifie que chaque fois qu'un programme script est sur le point d'être compilé, dont le code source est identique à celui d'un autre programme récemment qui a été récemment compilé, nous réutilisons la sortie précédente du programme de compilateur et sautons entièrement l'étape de compilation. Ce cache est assez efficace dans les scénarios de navigation typiques, où l'on charge page après page page après page du même site, comme différents articles d'un service d'information, puisque service de nouvelles, puisque chaque page charge souvent la même, parfois très grande, bibliothèque script.

Par conséquent, JavaScript est mis en cache lors des rechargements de page, deux requêtes vers le même script n'entraîneront pas de recompilation.

Source :


Firefox : Moteur SpiderMonkey

SpiderMonkey utilise Nanojit comme son back-end natif, un compilateur JIT. Le processus de compilation du code machine peut être vu comme suit ici . En bref, il apparaît pour recompiler les scripts au fur et à mesure qu'ils sont chargés. Cependant, si nous regardons de plus près aux internes de Nanojit nous voyons que le moniteur de niveau supérieur jstracer qui est utilisé pour suivre la compilation peut passer par trois étapes au cours de la compilation, ce qui constitue un avantage pour Nanojit :

L'état initial du moniteur de suivi est le suivi. Cela signifie que spidermonkey interprète le bytecode. Chaque fois que spidermonkey interprète un bytecode de saut en arrière, le moniteur prend note du nombre de fois que la valeur du compteur de programme (PC) de la cible de saut a été sautée. Ce nombre est appelé " hit count " pour le PC. Si le nombre d'occurrences d'un PC particulier atteint une valeur seuil, la cible est considérée comme considérée comme chaude.

Quand le moniteur décide qu'un PC cible est chaud, il regarde dans une table de hachage de fragments pour voir s'il y a un fragment contenant du code natif pour ce PC cible. S'il trouve un tel fragment, il passe à l'étape de mode exécution. Sinon, il passe en mode enregistrement.

Cela signifie que pour hot fragments de code le code natif est mis en cache. Ce qui signifie qu'il ne sera pas nécessaire de le recompiler. Il n'est pas précisé si ces sections natives hachées sont conservées entre les rafraîchissements de la page. Mais je suppose qu'elles le sont. Si quelqu'un peut trouver des preuves à l'appui de cette affirmation, alors excellent.

EDIT : Il a été signalé que Boris Zbarsky, développeur de Mozilla, a déclaré que Gecko ne met pas en cache les scripts compilés. mais . Tiré de cette réponse SO .


Safari : Moteur JavaScriptCore/SquirelFish

Je pense que la meilleure réponse à cette implémentation a déjà été donnée. a été donné par quelqu'un d'autre .

Actuellement, nous ne mettons pas en cache le bytecode (ou le code natif). Il s'agit d'un
option que nous avons envisagée, cependant, actuellement, la génération de code est une
partie triviale du temps d'exécution de JS (< 2%), donc nous ne poursuivons pas
pour le moment.

Ce texte a été rédigé par Maciej Stachowiak le développeur principal de Safari. Donc je pense que nous pouvons considérer cela comme vrai.

Je n'ai pas pu trouver d'autres informations, mais vous pouvez en savoir plus sur les améliorations de la vitesse du dernier SquirrelFish Extreme moteur ici ou parcourir le code source ici si vous vous sentez aventureux.


IE : Chakra Engine

Il n'y a pas d'informations actuelles concernant le moteur JavaScript d'IE9 (Chakra) dans ce domaine. Si quelqu'un sait quelque chose, veuillez commenter.

C'est assez peu officiel, mais pour les anciennes implémentations du moteur d'IE, Eric Lippert ( un développeur MS de JScript ) déclare dans une réponse à un blog ici que :

JScript Classic se comporte comme un langage compilé dans le sens où, avant l'exécution de tout programme JScript Classic, nous effectuons un contrôle syntaxique complet du code, nous générons un arbre d'analyse complet et un bytecode. Nous exécutons ensuite le bytecode à travers un interpréteur de bytecode. En ce sens, JScript est tout aussi "compilé" que Java. La différence est que JScript ne vous permet pas de persister ou d'examiner notre bytecode propriétaire. . De plus, le bytecode est beaucoup plus élevé que le bytecode de la JVM -- le bytecode de JScript Classic n'est guère plus qu'une linéarisation de l'arbre d'analyse, alors que le bytecode de la JVM est clairement destiné à fonctionner sur une machine à pile de bas niveau.

Cela suggère que le bytecode ne persiste d'aucune façon, et donc que le bytecode n'est pas mis en cache.

12voto

cha0site Points 5675

Opera le fait, comme mentionné dans l'autre réponse. ( source )

Firefox (moteur SpiderMonkey) fait pas cache bytecode. ( source )

WebKit (Safari, Konqueror) fait pas cache bytecode. ( source )

Je ne suis pas sûr pour IE [6/7/8] ou V8 (Chrome), je pense que IE pourrait faire une sorte de mise en cache alors que V8 peut ne pas le faire. IE est closed source donc je ne suis pas sûr, mais dans V8, cela n'a peut-être pas de sens de mettre en cache du code "compilé" puisqu'ils compilent directement en code machine.

3voto

gsnedders Points 2693

Pour autant que je sache, seul Opera met en cache le JavaScript analysé. Voir la section "Programmes compilés mis en cache". ici .

2voto

igrigorik Points 3961

Cela ne vaut rien que Google Dart s'attaque explicitement à ce problème par le biais de "Snapshots" - l'objectif est d'accélérer le temps d'initialisation et de chargement en chargeant la version préparée du code.

InfoQ a un bon compte-rendu @ http://www.infoq.com/articles/google-dart

0voto

Abhidev Points 1976

Le navigateur utilise certainement la mise en cache mais oui, les navigateurs analysent le JavaScript à chaque fois qu'une page est rafraîchie. Parce que chaque fois qu'une page est chargée par le navigateur, il crée 2 arbres 1. l'arbre du contenu et 2. l'arbre de rendu.

Cet arbre de rendu contient des informations sur la disposition visuelle des éléments du domaine. Ainsi, chaque fois qu'une page se charge, le javascript est analysé et tout changement dynamique effectué par le javascript, comme le positionnement de l'élément dom, l'affichage ou la masquage de l'élément, l'ajout ou le retrait de l'élément, obligera le navigateur à recréer l'arbre de rendu. Mais les navigateurs modernes comme FF et Chrome gèrent cela légèrement différemment, ils ont le concept de rendu incrémentiel, donc à chaque fois qu'il y a des changements dynamiques par le javascript comme mentionné ci-dessus, il ne fera que rendre et repeindre ces éléments à nouveau.

Prograide.com

Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.

Powered by:

X