Questi sono i dettagli che sono stato in grado di scavare. Vale la pena notare innanzitutto che sebbene JavaScript sia generalmente interpretato ed eseguito su una macchina virtuale, questo non è il caso degli interpreti moderni, che tendono a compilare il sorgente direttamente nel codice macchina (ad eccezione di IE).
Chrome: motore V8
V8 ha una cache di compilazione. Questo memorizza JavaScript compilato utilizzando un hash dell'origine per un massimo di 5 garbage collection. Ciò significa che due parti identiche di codice sorgente condivideranno una voce di cache in memoria indipendentemente dal modo in cui sono state incluse. Questa cache non viene cancellata quando le pagine vengono ricaricate.
fonte
Aggiornamento - 19/03/2015
Il team di Chrome ha rilasciato dettagli sulle loro nuove tecniche per lo streaming e la memorizzazione nella cache di JavaScript .
- Streaming degli script
Lo streaming di script ottimizza l'analisi dei file JavaScript. [...]
A partire dalla versione 41, Chrome analizza gli script asincroni e posticipati su un thread separato non appena il download è iniziato. Ciò significa che l'analisi può essere completata in pochi millisecondi al termine del download e il caricamento delle pagine è del 10% più veloce.
- Memorizzazione nella cache del codice
Normalmente, il motore V8 compila il JavaScript della pagina ad ogni visita, trasformandolo in istruzioni comprensibili per un processore. Questo codice compilato viene quindi scartato una volta che l'utente si allontana dalla pagina poiché il codice compilato dipende fortemente dallo stato e dal contesto della macchina al momento della compilazione.
Chrome 42 introduce una tecnica avanzata di archiviazione di una copia locale del codice compilato, in modo che quando l'utente ritorna alla pagina, tutti i passaggi di download, analisi e compilazione possano essere saltati. Attraverso tutti i carichi di pagina, ciò consente a Chrome di evitare circa il 40% dei tempi di compilazione e di risparmiare preziosa batteria sui dispositivi mobili.
Opera: Carakan Engine
In pratica ciò significa che ogni volta che un programma di script sta per essere compilato, il cui codice sorgente è identico a quello di qualche altro programma che è stato recentemente compilato, riutilizziamo l'output precedente dal compilatore e saltiamo completamente il passaggio di compilazione. Questa cache è abbastanza efficace negli scenari di navigazione tipici in cui si carica una pagina dopo l'altra dallo stesso sito, ad esempio articoli di notizie diversi da un servizio di notizie, poiché ogni pagina carica spesso la stessa libreria di script, talvolta molto grande.
Pertanto JavaScript viene memorizzato nella cache tra i ricarichi di pagina, due richieste allo stesso script non comporteranno la ricompilazione.
fonte
Firefox: SpiderMonkey Engine
SpiderMonkey utilizza Nanojitcome back-end nativo un compilatore JIT. Il processo di compilazione del codice macchina può essere visto qui . In breve, sembra ricompilare gli script mentre vengono caricati. Tuttavia, se osserviamo più da vicino gli interni Nanojit, vediamo che il monitor di livello superiore jstracer, che viene utilizzato per tracciare la compilazione, può passare attraverso tre fasi durante la compilazione, fornendo un vantaggio a Nanojit:
Lo stato iniziale del monitor di traccia è il monitoraggio. Ciò significa che spidermonkey sta interpretando il bytecode. Ogni volta che spidermonkey interpreta un bytecode di salto all'indietro, il monitor prende nota del numero di volte in cui è stato saltato il valore del PC (counter-target program-counter). Questo numero è chiamato conteggio dei risultati per il PC. Se il conteggio dei colpi di un determinato PC raggiunge un valore di soglia, l'obiettivo viene considerato caldo.
Quando il monitor decide che un PC di destinazione è caldo, viene visualizzato in una tabella di frammenti per vedere se esiste un frammento che contiene il codice nativo per quel PC di destinazione. Se trova un tale frammento, passa alla modalità di esecuzione. Altrimenti passa alla modalità di registrazione.
Ciò significa che per hotframmenti di codice il codice nativo viene memorizzato nella cache. Significa che non sarà necessario ricompilare. Non è chiaro se queste sezioni native con hash vengono mantenute tra gli aggiornamenti di pagina. Ma suppongo che lo siano. Se qualcuno può trovare prove a sostegno di questo, allora eccellente.
EDIT : E 'stato sottolineato che Mozilla sviluppatore Boris Zbarsky ha dichiarato che Gecko non di cache compilato script ancora . Tratto da questa risposta SO .
Safari: JavaScriptCore / SquirelFish Engine
Penso che la migliore risposta per questa implementazione sia già stata data da qualcun altro .
Al momento non memorizziamo nella cache il bytecode (o il codice nativo). È
un'opzione che abbiamo considerato, tuttavia, attualmente, la generazione di codice è una
porzione banale del tempo di esecuzione di JS (<2%), quindi
al momento non lo stiamo perseguendo .
Questo è stato scritto da Maciej Stachowiak , lo sviluppatore principale di Safari. Quindi penso che possiamo ritenerlo vero.
Non sono stato in grado di trovare altre informazioni, ma puoi leggere di più sui miglioramenti di velocità dell'ultimo SquirrelFish Extrememotore qui o sfogliare il codice sorgente qui se ti senti avventuroso.
IE: Chakra Engine
In questo campo non sono disponibili informazioni relative al motore JavaScript (Chakra) di IE9. Se qualcuno sa qualcosa, si prega di commentare.
Questo è abbastanza non ufficiale, ma per le precedenti implementazioni del motore di IE, Eric Lippert ( uno sviluppatore MS di JScript ) afferma in un blog di rispondere qui che:
JScript Classic si comporta come un linguaggio compilato, nel senso che prima dell'esecuzione di qualsiasi programma JScript Classic, controlliamo completamente la sintassi del codice, generiamo un albero di analisi completo e generiamo un bytecode. Quindi eseguiamo il bytecode attraverso un interprete bytecode. In tal senso, JScript è "compilato" come Java. La differenza è che JScript non ti consente di persistere o esaminare il nostro bytecode proprietario . Inoltre, il bytecode è di livello molto più elevato rispetto al bytecode JVM: il linguaggio bytecode JScript Classic è poco più di una linearizzazione dell'albero di analisi, mentre il bytecode JVM è chiaramente concepito per funzionare su una macchina stack di basso livello.
Ciò suggerisce che il bytecode non persiste in alcun modo e quindi il bytecode non viene memorizzato nella cache.