Estos son los detalles que he podido desenterrar. Vale la pena señalar primero que, aunque generalmente se considera que JavaScript se interpreta y ejecuta en una VM, este no es realmente el caso con los intérpretes modernos, que tienden a compilar la fuente directamente en el código de la máquina (con la excepción de IE).
Chrome: motor V8
V8 tiene un caché de compilación. Esto almacena JavaScript compilado usando un hash de la fuente para hasta 5 recolecciones de basura. Esto significa que dos partes idénticas de código fuente compartirán una entrada de caché en la memoria, independientemente de cómo se incluyeron. Este caché no se borra cuando se vuelven a cargar las páginas.
Fuente
Actualización - 19/03/2015
El equipo de Chrome ha publicado detalles sobre sus nuevas técnicas para la transmisión y el almacenamiento en caché de JavaScript .
- Streaming de guiones
La transmisión de secuencias de comandos optimiza el análisis de archivos JavaScript. [...]
A partir de la versión 41, Chrome analiza los scripts asíncronos y diferidos en un hilo separado tan pronto como la descarga ha comenzado. Esto significa que el análisis puede completar solo milisegundos después de que la descarga haya finalizado, y hace que las páginas se carguen hasta un 10% más rápido.
- Almacenamiento en caché de código
Normalmente, el motor V8 compila el JavaScript de la página en cada visita, convirtiéndolo en instrucciones que entiende un procesador. Este código compilado se descarta una vez que un usuario navega fuera de la página, ya que el código compilado depende en gran medida del estado y el contexto de la máquina en el momento de la compilación.
Chrome 42 presenta una técnica avanzada para almacenar una copia local del código compilado, de modo que cuando el usuario regrese a la página, se puedan omitir los pasos de descarga, análisis y compilación. En todas las cargas de página, esto permite que Chrome evite aproximadamente el 40% del tiempo de compilación y ahorre una batería preciosa en dispositivos móviles.
Opera: motor Carakan
En la práctica, esto significa que siempre que un programa de script está a punto de compilarse, cuyo código fuente es idéntico al de otro programa que se compiló recientemente, reutilizamos el resultado anterior del compilador y omitimos el paso de compilación por completo. Esta memoria caché es bastante efectiva en escenarios de navegación típicos en los que se carga página tras página desde el mismo sitio, como artículos de noticias diferentes de un servicio de noticias, ya que cada página a menudo carga la misma biblioteca de scripts, a veces muy grande.
Por lo tanto, JavaScript se almacena en caché en las recargas de la página, dos solicitudes al mismo script no darán lugar a una nueva compilación.
Fuente
Firefox: motor de SpiderMonkey
SpiderMonkey utiliza Nanojitcomo su back-end nativo, un compilador JIT. El proceso de compilación del código de la máquina se puede ver aquí . En resumen, parece recompilar los scripts a medida que se cargan. Sin embargo, si echamos un vistazo más de cerca a las partes internas Nanojit, vemos que el monitor de nivel superior jstracer, que se utiliza para realizar un seguimiento de la compilación, puede realizar la transición a través de tres etapas durante la compilación, proporcionando un beneficio para Nanojit:
El estado inicial del monitor de rastreo es el monitoreo. Esto significa que spidermonkey está interpretando bytecode. Cada vez que spidermonkey interpreta un bytecode de salto hacia atrás, el monitor toma nota de la cantidad de veces que se saltó el valor del contador de programa (PC) del objetivo de salto. Este número se llama el recuento de visitas para la PC. Si el recuento de visitas de una PC en particular alcanza un valor umbral, el objetivo se considera activo.
Cuando el monitor decide que una PC de destino está activa, busca en una tabla hash de fragmentos para ver si hay un fragmento que contenga código nativo para esa PC de destino. Si encuentra dicho fragmento, pasa al modo de ejecución. De lo contrario, pasa al modo de grabación.
Esto significa que para los hotfragmentos de código, el código nativo se almacena en caché. Lo que significa que no será necesario volver a compilar. No está claro si estas secciones nativas hash se retienen entre las actualizaciones de la página. Pero supongo que lo son. Si alguien puede encontrar evidencia de apoyo para esto, entonces excelente.
EDITAR : Se ha señalado que el desarrollador de Mozilla Boris Zbarsky ha declarado que no Gecko compilado caché guiones todavía . Tomado de esta respuesta SO .
Safari: JavaScriptCore / SquirelFish Engine
Creo que la mejor respuesta para esta implementación ya la ha dado otra persona .
Actualmente no almacenamos en caché el código de bytes (o el código nativo). Es una
opción que hemos considerado, sin embargo, actualmente, la generación de código es una
parte trivial del tiempo de ejecución de JS (<2%), por lo que no estamos buscando
esto en este momento.
Esto fue escrito por Maciej Stachowiak , el desarrollador principal de Safari. Así que creo que podemos tomar eso como cierto.
No pude encontrar ninguna otra información, pero puedes leer más sobre las mejoras de velocidad del último SquirrelFish Extrememotor aquí , o navegar por el código fuente aquí si te sientes aventurero.
IE: Chakra Engine
No hay información actual sobre el motor JavaScript de IE9 (Chakra) en este campo. Si alguien sabe algo, por favor comente.
Esto no es oficial, pero para las implementaciones de motores más antiguas de IE, Eric Lippert ( un desarrollador de MS de JScript ) afirma en una respuesta de blog aquí que:
JScript Classic actúa como un lenguaje compilado en el sentido de que antes de que se ejecute cualquier programa JScript Classic, verificamos completamente el código, generamos un árbol de análisis completo y generamos un código de bytes. Luego ejecutamos el bytecode a través de un intérprete de bytecode. En ese sentido, JScript está tan "compilado" como Java. La diferencia es que JScript no le permite persistir ni examinar nuestro código de bytes patentado . Además, el código de bytes tiene un nivel mucho más alto que el código de bytes JVM: el lenguaje de código de bytes JScript Classic es poco más que una linealización del árbol de análisis, mientras que el código de bytes JVM está claramente destinado a operar en una máquina de pila de bajo nivel.
Esto sugiere que el código de bytes no persiste de ninguna manera y, por lo tanto, el código de bytes no se almacena en caché.