Це деталі, які мені вдалося розкопати. Спершу варто зазначити, що хоча JavaScript зазвичай вважається інтерпретованим та працює на VM, це насправді не так у сучасних інтерпретаторів, які, як правило, збирають джерело безпосередньо в машинний код (за винятком IE).
Chrome: V8 Engine
V8 має кеш-компіляцію. Цей магазин зберігає JavaScript, використовуючи хеш-код джерела для до 5 сміттєзбірників. Це означає, що два однакові фрагменти вихідного коду поділять запис кешу в пам'яті незалежно від того, як вони були включені. Цей кеш не очищається при перезавантаженні сторінок.
Джерело
Оновлення - 19.03.2015
Команда Chrome опублікувала детальну інформацію про свої нові методи потокового передавання та кешування JavaScript .
- Потокове сценарій
Потоковий сценарій оптимізує розбір файлів JavaScript. [...]
Починаючи з версії 41, Chrome розбирає асинхронізацію та відкладає сценарії в окрему нитку, як тільки завантаження розпочалося. Це означає, що синтаксичний аналіз може закінчитися лише за кілька мілісекунд після закінчення завантаження, а результат завантаження сторінок на 10% швидше.
- Кешування коду
Зазвичай V8 двигун збирає JavaScript сторінки кожного відвідування, перетворюючи його на інструкції, які розуміє процесор. Цей скомпільований код відкидається, як тільки користувач відходить від сторінки, оскільки складений код сильно залежить від стану та контексту машини під час компіляції.
Chrome 42 запроваджує вдосконалену техніку зберігання локальної копії скомпільованого коду, так що, коли користувач повернеться на сторінку, кроки завантаження, розбору та компілювання можуть бути пропущені. При всіх завантаженнях сторінок це дозволяє Chrome уникати близько 40% часу на компіляцію та економить дорогоцінний акумулятор на мобільних пристроях.
Опера: Караканський двигун
На практиці це означає, що щоразу, коли збирається скласти програму скриптів, вихідний код якої ідентичний тим, який був недавно скомпільований іншою програмою, ми повторно використовуємо попередній вихід із компілятора і повністю пропускаємо етап компіляції. Цей кеш досить ефективний у типових сценаріях перегляду, коли одна сторінка завантажує сторінку за сторінкою з одного веб-сайту, наприклад, різні статті новин служби новин, оскільки кожна сторінка часто завантажує ту саму, іноді дуже велику бібліотеку сценаріїв.
Тому JavaScript кешується через перезавантаження сторінок, два запити на один і той же сценарій не призведуть до повторної компіляції.
Джерело
Firefox: SpiderMonkey Engine
SpiderMonkey використовує Nanojitяк власний бек-енд, компілятор JIT. Процес складання машинного коду можна побачити тут . Коротше кажучи, видається, що перекомпілювати сценарії під час завантаження. Однак якщо ми уважніше подивимось на внутрішні положення, Nanojitто побачимо, що монітор вищого рівня jstracer, який використовується для відстеження компіляції, може під час компіляції переходити через три етапи, забезпечуючи перевагу Nanojit:
Початковий стан монітора слідів - це моніторинг. Це означає, що людина-павук інтерпретує байт-код. Кожен раз, коли spidermonkey інтерпретує байт-код перескоку назад, монітор зазначає, скільки разів було перескочено значення цільового програмного лічильника (PC). Це число називається підрахунком звернень для ПК. Якщо кількість вражень для певного ПК досягає порогового значення, ціль вважається гарячою.
Коли монітор вирішує, що цільовий ПК є гарячим, він переглядає фрагменти фрагментів, щоб побачити, чи є фрагмент, у якому є власний код цього цільового ПК. Якщо він знайде такий фрагмент, він переходить у режим виконання. В іншому випадку він переходить у режим запису.
Це означає, що для hotфрагментів коду натурний код кешується. Це означає, що не потрібно буде перекомпілювати. Не зрозуміло, чи зберігаються ці хешовані нативні розділи між оновленнями сторінок. Але я б припустив, що вони є. Якщо хтось може знайти підтвердження для цього, то відмінно.
EDIT : Це було відзначено, що Mozilla розробник Борис Збарський заявив , що Gecko НЕ кеш скомпільована сценарії ще . Взято з цієї відповіді ТА .
Safari: JavaScriptCore / SquirelFish Engine
Я думаю, що найкращу відповідь на цю реалізацію вже дав хтось інший .
Наразі ми не кешуємо байт-кодом (або нативним кодом). Це
варіант, який ми розглядали, однак, наразі генерація коду є
тривіальною частиною часу виконання JS (<2%), тому
наразі ми цього не переслідуємо .
Про це написав Maciej Stachowiak , провідний розробник Safari. Тому я думаю, що ми можемо вважати це правдою.
Я не зміг знайти будь-яку іншу інформацію , але ви можете прочитати більше про поліпшення швидкості новітнього SquirrelFish Extremeдвигуна тут , або переглянути вихідний код тут , якщо ви відчуваєте пригоди.
IE: Двигун чакри
Немає поточної інформації щодо IE9 JavaScript Engine (Chakra) в цьому полі. Якщо хтось щось знає, будь ласка, прокоментуйте.
Це цілком неофіційне, але для більш старих реалізацій двигуна в IE, Ерік Ліпперта ( розробник МС JScript ) стверджує в блозі відповіді тут , що:
JScript Classic діє як скомпільована мова в тому сенсі, що перед запуском будь-якої програми JScript Classic ми повністю перевіряємо синтаксис коду, генеруємо дерево повного розбору та генеруємо байт-код. Потім ми запускаємо байт-код через інтерпретатор байт-коду. У цьому сенсі JScript кожен біт так само "компілюється", як і Java. Різниця полягає в тому, що JScript не дозволяє зберігати або перевіряти наш власний байт-код . Також байт-код набагато вищого рівня, ніж байт-код JVM - мова байт-коду JScript Classic трохи більше, ніж лінеаризація дерева розбору, тоді як байт-код JVM явно призначений для роботи на низькорівневій машині стека.
Це говорить про те, що байт-код не зберігається жодним чином, і, таким чином, байт-код не кешується.