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.
