Ленивый парсинг и пре-парсер

Два парсера, а не один

Предыдущий урок описывал «парсер» как одну штуку. На деле V8 поставляет два парсера, разделяющих сканер. Понимание того, какой из них работает и когда, позволяет рассуждать о стоимости старта, а не просто гадать:

• Полный парсер. Строит полное AST, разрешает области видимости переменных, аллоцирует объекты областей видимости — всё, что нужно генератору байт-кода. Это дорогой.
• PreParser. Намеренно неполный парсер, который быстро бегло проходит тело функции. Он не строит AST и не аллоцирует области видимости. Его задача узка: найти, где функция заканчивается (чтобы движок знал диапазон байтов, к которому вернуться), и обнаружить ранние ошибки — синтаксические ошибки и горстку проблем класса SyntaxError (return вне функции, дублирующийся параметр в strict-режиме), которые спецификация требует сообщать даже для кода, который никогда не выполняется.

При холодной загрузке V8 не парсит большинство тел функций полностью. Он их пре-парсит: бегло проходит, записывает диапазон исходника и немного метаданных, идёт дальше. Полный парсинг данной функции откладывается до момента, когда функцию впервые вызовут. Это ленивый парсинг, и это крупнейший выигрыш на старте во фронт-энд конвейере, потому что большинство функций в типичном бандле на холодном пути никогда не вызываются.

Ловушка: вызванная функция парсится дважды

Ленивый парсинг — это ставка. Ставка окупается для функций, которые никогда не вызываются: вы потратили один дешёвый беглый проход вместо одного дорогого полного парсинга. Но для функции, которую вызывают, вы проигрываете ставку — вы платите за беглый pre-parse и затем за полный парсинг. Это проблема двойного парсинга: лениво распарсенная функция, которая позже выполняется, стоит примерно 2× работы парсинга по сравнению с функцией, распарсенной жадно один раз.

Для большинства кода это правильный компромисс: экономия на никогда не вызываемом большинстве перевешивает двойную стоимость на вызываемом меньшинстве. Но на горячем стартовом пути — функции, про которые вы знаете, что они выполняются сразу, вроде бутстрапа вашего фреймворка или инициализатора верхнего уровня модуля — платить за два парсинга это чистая трата. Вы бы предпочли, чтобы V8 просто распарсил их жадно, один раз.

Эвристика жадного парсинга: скобки значат «запусти меня сейчас»

У V8 есть эвристика, чтобы вывести функцию из ленивого парсинга: если функциональное выражение обёрнуто в скобки, V8 парсит его жадно, потому что скобки — классический сигнал немедленно вызываемого функционального выражения (IIFE) — функции, которую автор намерен вызвать сразу.

// Парсится жадно: скобки сигнализируют «это выполняется немедленно».
(function () {
  bootstrapTheApp();
})();

// По умолчанию парсится лениво: выглядит как определение для вызова позже.
function maybeLater() {
  doExpensiveThing();
}

Функцию, написанную так, чтобы выглядеть как IIFE — даже со скобками, но вызываемую отдельно — называют PIFE (Possibly-Invoked Function Expression), и V8 трактует ведущую ( как подсказку жадного парсинга. Это ровно тот трюк, который эксплуатировал старый инструмент optimize-js: он механически оборачивал функции бутстрапа модулей в скобки, чтобы V8 парсил их жадно и пропускал двойной парсинг на стартовом пути. Современные сборщики (webpack, Rollup) выпускают обёртки IIFE/PIFE вокруг фабрик модулей по той же причине — это реальная, измеримая оптимизация старта, а не фольклор.

Вложенные функции едут вместе со своей внешней функцией

Есть структурная тонкость: когда V8 полностью парсит внешнюю функцию, он пре-парсит вложенные внутри неё функции — он не парсит их тоже полностью. Так что глубоко вложенный хелпер пре-парсится, когда его охватывающая функция парсится полностью, и парсится полностью лишь тогда, когда этот внутренний хелпер сам впервые вызван. Лень рекурсивна: каждый уровень откладывает следующий. Вот почему гигантская функция уровня модуля со множеством вложенных замыканий всё равно может стартовать дёшево — вложенность бегло проходится, а не строится полностью, пока каждый кусок не запустится.