Почему ваш микробенчмарк врёт

Почему JIT — противник вашего бенчмарка

Прежде чем написать следующий цикл-бенчмарк, спросите себя: что TurboFan делает с вычислением, результат которого никто не наблюдает? Он его удаляет — полностью. В этом корень каждой ловушки ниже.

Микробенчмарк — это крошечная программа, вывод которой вы игнорируете, прогоняемая в плотном цикле — ровно та программа, которую оптимизирующий компилятор лучше всего умеет сносить. Вся работа TurboFan — убрать работу, не влияющую на наблюдаемое поведение. Если результат вашего бенчмарка никогда не наблюдается, то работа, его породившая, по определению устранима. Ловушки ниже — все следствия того, что оптимизатор делает свою работу над кодом, который вы не намеревались оптимизировать в ничто.

Ловушка 1 — устранение мёртвого кода (DCE)

Если тело цикла вычисляет значение, которое никто не читает, оптимизатор доказывает, что вычисление наблюдаемо бесполезно, и удаляет его. Ваш бенчмарк «1 миллиард операций» становится пустым циклом — иногда удаляется и сам цикл. Фикс — это black-hole sink: накапливайте каждый результат в переменную, которую читаете после замеряемой зоны (и в идеале печатаете или возвращаете), чтобы оптимизатор не смог доказать, что работа мёртвая.

// ОБМАН — результат выброшен, тело устранено
for (let i = 0; i < 1e9; i++) { expensive(i); }

// ЧЕСТНО — sink делает работу наблюдаемой
let sink = 0;
for (let i = 0; i < 1e9; i++) { sink += expensive(i); }
console.log(sink); // read it so DCE cannot remove the loop

Ловушка 2 — свёртка констант и вынос инвариантов цикла

Если вход — это литеральная константа, оптимизатор вычисляет ответ один раз на этапе компиляции (свёртка констант), и ваш цикл мерит ничто. Если подвыражение не меняется между итерациями, оно выносится из цикла (вынос инвариантного кода) и выполняется один раз вместо N. Фикс: делайте входы непредсказуемо меняющимися — выводите их из индекса цикла или заранее сгенерированного массива случайных значений, которые оптимизатор не может вычислить заранее («blackbox»-вход).

Ловушка 3 — неучтённый разогрев JIT

Первые итерации идут в Ignition (интерпретируются), затем в Sparkplug, затем в Maglev/TurboFan, как только функция станет горячей. Если замерять с итерации ноль, вы усредняете холодную интерпретацию, паузы компиляции и установившийся машинный код в одно бессмысленное число — и «быстрый» результат может быть просто слишком коротким бенчмарком, который никогда не достигнет TurboFan. Отбросьте фазу разогрева, затем замеряйте; или сообщайте ярусы отдельно, если важны оба — и старт, и установившееся состояние.

Ловушка 4 — OSR посреди измерения

Один гигантский цикл for может вызвать on-stack replacement: V8 компилирует и подставляет оптимизированный код пока цикл ещё выполняется, так что ранняя часть того самого цикла, который вы мерите, идёт интерпретируемо, а остаток — оптимизированно — разрыв, вшитый в одну выборку. Предпочитайте много вызовов меньшей бенчмарк-функции (это разогревает функцию, а не один цикл) одному огромному циклу.

Ловушка 5 — шум GC в замеряемой зоне

Если тело аллоцирует, сборщик мусора рано или поздно встанет на паузу внутри вашего измерения, приписав время GC вашему коду как случайный всплеск. Либо уберите аллокацию из замеряемой зоны, либо прогоните бенчмарк много раз и сообщайте устойчивую статистику (медиана/минимум), а не среднее, чтобы шальная пауза GC не доминировала. Сообщайте распределение, а не одно число.

Ловушка 6 — деопты, которые вы протащили в замеряемую зону

console.log внутри замеряемого цикла, try/catch, через который V8 не будет оптимизировать, или полиморфный вызов, внесённый самим стендом, могут деоптить ту самую функцию, которую вы мерите — так что вы мерите деоптимизированную версию. Держите замеряемую зону чистой: без логирования, без исключений, одна стабильная форма и тип, и проверьте через --trace-deopt, что горячая функция не откатывается во время замера.

Ловушка 7 — несовпадение micro и macro

Даже идеальный микробенчмарк отвечает лишь на вопрос «насколько быстр этот изолированный паттерн в синтетическом цикле». Ваше приложение выполняет его вперемешку с другой работой, с холодными кэшами, реальными распределениями входов и конкуренцией за GC — где победитель micro может проиграть. Микробенчмарки выбирают между двумя реализациями известного горячего места; они не говорят, что это горячее место важно. Для сквозной правды используйте macro-наборы (JetStream, Speedometer) или профилируйте настоящее приложение. Для честных micro-чисел используйте стенд, построенный побеждать эти ловушки: tinybench или mitata берут на себя разогрев, sink и статистику.