Объекты в JS не бесплатные

Почему обычный [object Object] иногда становится дорогим — и как одна строка делает исполнение кода медленнее.

zero deps · talks @zero_deps

кто здесь?

Василий Каменюк

role staff инженер · ONRTools Инструменты для удалённой работы с CAN-шиной автомобилей. Node.js, Electron, Vue.

prod 6 лет, чистый JS Финтех в проде. Сбор данных, reverse engineering и автоматизация внешних систем.

tg @zero_deps Node.js, V8, highload, архитектура.
Всё, что ставим — потом и поддерживаем.
Фиксим то, что сами и сломали.

план

О чём поговорим

01 V8 как адаптивная система

02 Hidden classes, transition tree, inline cache

03 Где теряется shape

04 Цифры

интерактивчик

Где быстрее чтение?

a — literal

const a = {
  id: 1,
  name: 'v',
  age: 30
}

b — stepwise

const b = {}

b.id = 1
b.name = 'v'
b.age = 30

Вспомните! кто писал delete obj.foo?

[2 мин]

— Небольшой интерактивчик. На слайде два кусочка кода. Слева — литерал, всё сразу. Справа — пустой объект и три присваивания. Обе функции делают одно и то же.

— Кто думает, что левый быстрее — пожалуйста поднимите руку. Так, ага. Кто за правый? Окей.

— Хорошо, замоните друг друга, ответ будет где-то в середине доклада =)

— клик

— А теперь второй вопрос. Кто недавно писал в коде delete obj.foo? Поднимите руку. Ага, вижу. Спасибо!

— Запомните этих людей. Ближе к концу доклада я расскажу, что они сделали с оптимизацией.

дисклеймер

Для 99% систем это не нужно

hot path — десятки тысяч объектов в секунду
library code — ваш код может крутится в чужих hot path
v8 perf — собеседования, диагностика и оптимизации

Drake meme: optimize CRUD vs optimize hot path

PiterJS · Алексей Козятинский

Podlodka React Crew · Анастасия Котова

Node Congress · Мерт Джан Алтын

[1 мин]

— Так же считаю нужным обозначить. То, о чём я буду говорить, нужно вам только в трёх случаях.

— Первое. У вас в проде десятки тысяч объектов в секунду на hot path.

— Второе. Вы пишите библиотеку, которая может работать в тяжелом проде

— А также будет полезно для собеса, чтобы блестнуть знаниями

— Но На самом деле перфоманс V8 довольно актуальная тема: на PiterJS был доклад Алексей Козятинского про переезд нетфликс на V8, на Подлодке Анастасия Котова рассказывала про V8 и работу с данными в React, а на последнем Node Congress Мерт Джан Алтын рассказывал про V8 GC и native-объекты.

— Приступим

V8 — адаптивная система

пайплайн

V8 не компилирует.

V8 адаптируется.

Ignition bytecode interpreter

Sparkplug baseline jit

Maglev mid-tier jit

TurboFan top-tier · цель

код прогревается и поднимается по тирам
на каждом тире V8 копит feedback
TurboFan спекулирует на типах и shape
deopt — откат с TurboFan в Ignition

[2.5 мин]

— V8 — это движок от Google. Он работает внутри Chrome, Node.js, Deno, Edge. Один и тот же код везде.

— Главное, что нужно понять: V8 не просто компилирует ваш JS в машинный код один раз. Он постоянно адаптируется. Он смотрит, как код реально работает. Какие типы приходят. Какие объекты передаются. И постепенно подкручивает себя под ваш конкретный код.

— Внутри несколько уровней исполнения.

— Ignition — быстрый интерпретатор. Быстро запускает код как байткод.

— Sparkplug и Maglev — промежуточные этапы оптимизации. Каждый немного умнее предыдущего, а главная цель это прогреться до TurboFan.

— TurboFan — верхний оптимизирующий компилятор. Включается для действительно горячего кода и выжимает максимум.

— Чтобы код стал быстрым, он должен прогреться. Просто запустился один раз — это Ignition. Часто вызывается — поднимется на Sparkplug, потом Maglev, потом TurboFan.

— Но есть и обратный путь. Называется deopt. Это когда оптимизированный код был построен на предположения которые оказались не верны. V8 откатывает выполнение на менее оптимизированный путь и позже может попробовать оптимизировать функцию снова.

— deopt Это главный антагонист всего доклада. К нему ещё вернёмся.

feedback

Feedback Vector

function getId(obj) {
  return obj.id // ← call site
}

feedback vector · slot[0]

state monomorphic

map Map#A2 · { id, name, age }

handler load · offset 0

call site — место чтения поля или вызова
feedback — какие формы реально приходили
guard — быстрый путь + проверка гипотезы
deopt — guard сорвался, прогрев заново

[2 мин]

— Когда я говорю, что V8 адаптируется, это не про гадание и авось попадет. Это про статистику. V8 все записывает в блокнотик.

— У каждой функции есть своя страница в блокноте. Называется feedback vector. И в нём V8 пишет: «вот здесь читали поле id — пришёл объект вот такой формы. Вот тут вызвали функцию — она получила число. Вот тут — строку».

— Когда функция вызвана много раз, TurboFan берёт эту старницу и говорит: «окей, я оптимизирую под то, что реально происходит. Если на входе всегда один тип объекта — я скомпилирую быстрый путь именно под него».

— Плюс поставлю — guard, проверку. Если прилетит что-то неожиданное, guard это поймайет и турбофан откатит оптимизацию. Тот самый deopt.

— Дальше поговорим про то, как v8 видит твои обьекты!

Hidden classes
transition tree
inline cache

hidden class

Объект — это не словарь

Map* → shared

id offset 0

name offset 1

age offset 2

фиксированный layout — массив значений
форма (Map) шарится между объектами одной формы
JIT подставляет offset прямо в машинный код
один { id, name, age } = одна Map на всех

[2 мин]

— Снаружи объект в JS выглядит как мешок ключей. В этот мешок можно напихать что угодно по любому имени. Но это только так выглядит. V8 показывает нам объект через свой API.

— Внутри это структура. Аналогия грубая, деталей больше, но суть примерно такая.

— Если упрощённо: у объекта есть ссылка на внутреннюю Map. Не путайте с Map, которую вы знаете из JavaScript. Это внутренняя штука V8. Ее еще называют её «форма», «hidden class» или «shape».

— Эта форма описывает объект: какие поля у него есть и где они лежат. Для нас сейчас важна не байтовая анатомия, а принцип что, V8 знает смещение, где лежит значение поля.

— Форма говорит: вот поле id, вот поле name, вот поле age и такие то смещения для доступа к данным.

— Самое важное стоит отметить: миллион объектов с одинаковыми полями шарят один hidden class. Не у каждого свой, а один на всех. И когда V8 видит чтение id, он может прямо в скомпилированный код подставить доступ по смещению. Никакого поиска по ключу.

— Это и есть тот fast path к которому мы стремимся.

transition tree

Один shape, разные пути

Maps связаны в дерево переходов
один порядок полей — одна Map
разный порядок — разные Map

[1.5 мин]

— Hidden class — не отдельные объекты в вакууме. Они связаны в дерево переходов.

— Допустим, создается пустой {} — это корень. Добавляется поле id — V8 идёт по ветке «добавили id». Далле name — и получаем еще одну ветку. И так миллион ваших юзеров идут по одной и той же тропинке. Все шарят одни и те же hidden classes.

— Но! Если сделать { name, id } вместо { id, name } — это другая тропинка. Другие hidden clases. Поля те же, выглядит одинаково, а внутри V8 — разные формы, разные ветки дерева.

— И именно это — разные формы на одном call site — то что V8 отслеживает через следующий механизм.

inline cache

IC: четыре формы — потолок

monomorphic прямой offset JIT подставляет offset поля прямо в машинный код. Никаких проверок, никаких ветвлений.

когда один shape всегда

1 shape · ~1.0 ns

polymorphic таблица из ≤4 Маленькая таблица из Map'ов, IC проверяет каждый — guard. Дешевле runtime, но не бесплатно.

когда 2–4 похожие формы

2–4 shapes · ~1.15 ns

megamorphic global stub cache Глобальная хэш-таблица на весь процесс. Промах — runtime call, и IC уже не оптимизируется.

когда 5+ разных shape'ов

5+ shapes · ~3.6 ns

[1.5 мин]

— Inline cache. На каждом месте в коде, где ты читаешь поле, V8 ставит кэш — IC. И он помнит, с каких веток приходили объекты.

— У этого кэша три состояния.

— Monomorphic — на это место всегда приходит одина форма. V8 знает смещение и подставляет его прямо в код. Быстро.

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

— Megamorphic — приходит пять и больше форм. V8 каждый раз делает поиск по глобальной хэш-таблице. В три-четыре раза медленнее.

— Поэтому Четыре формы объекта — это потолок, если мы хотим оптимизацию.

— Ладно, теория есть. Давайте теперь проверим её на конкретном примере. Том самом, что я спрашивал в начале.

literal vs stepwise

Same picture? Same picture.

// literal — V8 видит сразу всю форму
const a = {
  id: 1,
  name: 'v',
  age: 30
}

// stepwise — V8 строит форму по полю
const b = {}

b.id = 1
b.name = 'v'
b.age = 30

%HaveSameMap(a, b) → false · v8-флаг --allow-natives-syntax
Поля те же, порядок тот же — но Map'ы разные: literal-фабрика идёт по своему пути в transition tree.
На одном call site IC увидит две формы → polymorphic.

// смешали — IC видит две формы
function getId(obj) {
  return obj.id
}

getId(a) // Map#literal   → mono ✓
getId(b) // Map#stepwise  → poly ⚠

[1.5 мин]

— Литерал и stepwise. Вот конкретный кейс для всего, что мы только что разобрали.

— Я проверял через специальную внутреннюю функцию V8 — %HaveSameMap. Возвращает true, если у двух объектов одна и та же форма. На наших двух — false.

— Почему? Литерал V8 строит из готового шаблона, минует дерево переходов. Stepwise идёт через дерево по веткам. Финальные hidden classes — на разных ветках.

— При этом скорость чтения одинаковая. Потому что в коде они обычно живут в разных функциях. Каждое место в коде видит свой один тип. Monomorphic, fast path.

— Проблема начинается, когда их смешают в одной функции. Один call site — две формы. Polymorphic. Уже медленнее.

— Какой можно сделать вывод: писать можно как удобно, но Не смешивай подходы.

Где вы теряете shape

условные поля

Условное поле - уже две формы

function makeUser(id, name, isAdmin) {
  const user = {
    id,
    name
  }

  if (isAdmin) {
    user.role = 'admin'
  }

  return user
}

поля во всех фабриках — в одном порядке.
не знаете значение — запиши null.

[1.5 мин]

— А вот это уже более реальный код, который каждый может увидеть на ревью.

— Функция makeUser. Принимает id, name и флаг isAdmin. Если админ — добавляем поле role. Если нет — не добавляем.

— Что же происходит? Из одной фабрики получаем два разных типа объектов. У одного три поля, у другого два. Пока-что терпимо, инлайн кеш будет Polimorfic.

— Но. Если увлечься, условными полями, и наплодить десяток таких фабрик с разным порядком полей — мы упадем мегаморфизм. И получили медленный доступ к полям.

— Какой вывод? Парвильно: Сделать одну фарбику. Один порядок полей везде. Не знаешь значение — поставьте null. Поле в объекте есть, форма стабильная, V8 оптимизировал.

главный моментик

`delete` — это катастрофа

const user = {
  id: 1,
  name: 'v',
  tmp: 'love ts'
}

delete user.tmp

DictionaryProperties back pointer: undefined · объект выпал из transition tree каждое чтение поля → hash lookup, IC бесполезен

fix: user.tmp = null · поле остаётся в shape, IC живёт

29× медленнее чтение после одного delete

[3 мин]

— Вот и добрались до самого интересного.

— Помните руки в начале? Кто писал delete?

— А для чего вы его используете? Захотели почистить "память", удалить ссылку или значение. Как будто все просто и безопасно.

— А на деле в современных V8 delete переводит объект в dictionary mode. Объект теряет предсказуемую форму. Доступ к полю медленный, и выглядит как поиск свойства по ключу в словаре.

— Да, V8 теоретически может по новой оптимизировать, но практика показывает, что падение в деоптимизацию, в данном случае без возвратна.

— В моем Бенче на 22ой ноде, чтение поля после delete медленее в 29 раз чем fast path.

— Что бы этого избежать, забудь про delete. Лучше присвоить null. Поле осталось, форма стабильная, ссылку убрали, GC дальше разберется сам.

— Кто-то в зале может заметить: «А ведь в V8 же была оптимизация — если удаляешь последнее добавленное поле, объект откатывался обратно». Да, была. Об этом — через слайд.

deopt

Guard сорвался — deopt

триггер — delete, условное поле, разный порядок
цена — код в мусорку, прогрев заново
видно — пила на графике p99
лучше прогрева — не сбивать прогретое

[1.5 мин]

— А пока, Маленькая зарисовка про то, как всё ломается.

— TurboFan скомпилировал вашу функцию под форму X. Поставил guard. Всё ок, летим. И тут в функцию прилетает обьект с другим порядком полей или с лишним условным полем. Для V8 это уже форма Y.

— Guard ловит несовпадение. Оптимизированный код больше нельзя безопасно использовать. Кто-то сбил оптимизацию. V8 откатывает выполнение на менее оптимизированный путь и позже может снова попробовать оптимизировать функцию.

— Откат Не всегда прямо в ignition, но в любом случае будет медленнее.

— Это можно заметить на графике p99 после рестарта. Некоторое время будет пила, но Десять-двадцать тысяч итераций — и снова всё ровно.

— Каждый delete, каждое условное поле, каждая фабрика без дефолтов — это потенциальный триггер потери оптимального пути.

— Лучше прогрева — не сбивать прогретое.

Цифры
правила
контракт

методология

Как измерял

framework mitata — p50/p75/p99, защита от dead code elimination

setup 100k объектов предсозданы, в hot loop только obj.id

runs Node.js 20 / 22 / 24 = V8 11.3 / 12.4 / 13.6

смотрим пропорции и тренды, не абсолютные ns/iter

[1 мин]

— Кратко про методологию.

— Использовал библиотеку mitata — современный бенчмарк-фреймворк. Считает p50, p75, p99. Умеет защищаться от того, что V8 выкинет ваш код как мёртвый.

— Сто тысяч объектов уже созданы до начала измерения. В горячем цикле — только чтение поля. Без аллокаций, без GC.

— Прогон на трёх версиях Node.js — двадцатой, двадцать второй и двадцать четвёртой. Это три разных V8.

— Все абсолютные цифры — Apple M4. У вас могут быть другие. Я смотрю на пропорции и тренды.

цифры

Сводка · все замеры

case

Node.js 20 · V8 11.3

Node.js 22 · V8 12.4

Node.js 24 · V8 13.6

slowdown

state

literal

1.05 ns

1.06 ns

1.02 ns

×1.0

fast path

stepwise

1.03 ns

1.06 ns

1.07 ns

×1.0

fast path

polymorphic IC · 2 shapes

1.13 ns

1.19 ns

1.12 ns

×1.1

poly

megamorphic IC · 6 shapes

3.14 ns

3.30 ns

3.17 ns

×3.1

mega

delete → dictionary

1.06 ns

30.94 ns

14.08 ns

×30 / ×14

slow

literal / stepwise / poly / mega — стабильны от Node.js 20 до 24. Один путь сломан: delete уронил объект в dict mode в Node.js 22 и не вернулся в 24.

[1.5 мин]

— И вот как-то так получилось по бенчам

— Literal, stepwise, polymorphic, megamorphic — стабильны от Node.js 20 до Node.js 24. Цифры почти один в один. Fast path работает.

— Один путь сломан. delete.

— Node.js 20 — одна наносекунда. Как будто delete никак не повлиял.

— Node.js 22 — тридцать одна наносекунда. Тридцатикратное падение.

— Node.js 24 — четырнадцать. То есть всё ещё в четырнадцать раз медленнее, чем literal, но как будто, что то подкрутили.

— Это грустная история про то, как одна оптимизация ушла из V8 — и обратно не вернулась.

регрессия

V8 11.3 → 12.4: оптимизация ушла

Node.js 20 · V8 11.3

const u = { id: 1, tmp: 9 }
delete u.tmp % HasFastProperties(u)
// → true

fast path сохраняется

Node.js 22 · V8 12.4

const u = { id: 1, tmp: 9 }
delete u.tmp % HasFastProperties(u)
// → false

dictionary mode

Node.js 24 · V8 13.6

const u = { id: 1, tmp: 9 }
delete u.tmp % HasFastProperties(u)
// → false

dictionary mode

%HasFastProperties — внутренний предикат V8 (флаг --allow-natives-syntax).
Возвращает false, когда объект ушёл в dict mode. С Node.js 22+ это происходит после одного delete.

[1.5 мин]

— Ну и Немного пруфов.

— В V8 нет публичного способа узнать, в каком режиме объект — fast или slow. Но есть внутренний предикат, он указан на
слайде. Включается флагом.

— Три блока кода, одинаковых. На Node.js 20 — после delete u.tmp — предикат возвращает true. Объект остался
на fast path. Та самая оптимизация для последнего поля работала.

— На Node.js 22 — false. Dictionary mode. Оптимизацию убрали.

— На Node.js 24 — тоже false. Не вернули.

— Какбуд-то все таки не баг, а фича.

лог · node 22 · v8 12.4

`delete` уносит в dict mode · ×29

Node.js: v22.18.0 | V8: 12.4.254.21-node.27 | Apple M4

benchmark                     avg (min … max) p75 / p99    (min … top 1%)
--------------------------------------------- -------------------------------
• object shape: field read
--------------------------------------------- -------------------------------
literal (1 shape, fast path)     1.06 ns/iter   1.04 ns   █
                       (986.57 ps … 19.65 ns)   1.34 ns   █

stepwise (same order)            1.06 ns/iter   1.04 ns   █▃
                       (986.57 ps … 13.38 ns)   1.37 ns   ██

polymorphic IC (2 shapes)        1.19 ns/iter   1.16 ns  █
                         (1.11 ns … 18.57 ns)   1.70 ns  █

megamorphic IC (6 shapes)        3.30 ns/iter   3.19 ns █
                        (3.09 ns … 313.52 ns)   6.49 ns █

dictionary mode (after delete)  30.94 ns/iter  31.88 ns   █
                       (20.14 ns … 358.08 ns)  91.30 ns  ██▇

summary
  literal (1 shape, fast path)
   1x faster than stepwise (same order)
   1.13x faster than polymorphic IC (2 shapes)
   3.12x faster than megamorphic IC (6 shapes)
   29.31x faster than dictionary mode (after delete)

лог · node 24 · v8 13.6

fast path быстрее, dict — ×14

Node.js: v24.14.1 | V8: 13.6.233.17-node.44 | Apple M4

benchmark                     avg (min … max) p75 / p99    (min … top 1%)
--------------------------------------------- -------------------------------
• object shape: field read
--------------------------------------------- -------------------------------
literal (1 shape, fast path)     1.02 ns/iter   1.01 ns   █
                       (946.04 ps … 19.96 ns)   1.43 ns  ▄█

stepwise (same order)            1.07 ns/iter   1.03 ns  █
                      (956.05 ps … 901.39 ns)   2.11 ns  █

polymorphic IC (2 shapes)        1.12 ns/iter   1.11 ns   █
                         (1.04 ns … 15.59 ns)   1.56 ns   █

megamorphic IC (6 shapes)        3.17 ns/iter   3.11 ns █▅
                         (3.04 ns … 35.13 ns)   4.58 ns ██

dictionary mode (after delete)  14.08 ns/iter  16.30 ns   █▃
                         (7.46 ns … 92.08 ns)  34.50 ns  ▆██▄

summary
  literal (1 shape, fast path)
   1.05x faster than stepwise (same order)
   1.1x faster than polymorphic IC (2 shapes)
   3.12x faster than megamorphic IC (6 shapes)
   13.82x faster than dictionary mode (after delete)

Что же делать?

делать

литералы в hot pathвсе поля сразу, в одном порядке
один порядок во всех фабрикахсравнить makeUser и parseUser — поля идут в одинаковм порядке
дефолт вместо отсутствияне знаешь значение — null / undefined, но поле в shape
class или одна фабрика на типV8 любит стабильный конструктор

не делать

delete obj.propertyзамени на obj.property = null — shape стабильный
swiss-knife хелпер на 15 типоводин call site, 15 форм — мега-таблица, мееееедленно
Object.create(null) в hot path≈ 9× оверхед против обычного литерала
условные поля без дефолтаif (admin) user.role = ... — две формы из одной фабрики

[2 мин]

— Чтож делать? Чтож делать? Слайд выглядит как список правил. Но за каждым пунктом — то, что мы только что видели.

— Самое главное что «нужно делать» сохранить один порядок полей. Везде. makeUser, makeAdmin, parseUser — если они когда-нибудь встретятся на одном call site, IC должен увидеть одну форму. Есди Поля в разном порядке, формы будут разные и привет деоптимизация.

— Если Не знаешь значение при создании — ставишь null. Не пропускаешь поле. Форма фиксируется с рождения, потом меняются только значения.

— Если объект уже очень сложный используй class. Конструктор — это стабильный путь создания обьекта, V8 его любит.

— А Теперь «что делать не стоит». Тут покороче.

— Не используйте delete — вы уже видели цифры. В Node.js 22 — тридцать наносекунд против одной. Просто поставьте null. V8 вас поймет, GC отработает, форма останется.

— Не стоит использваоть Одну функция хелпер, которая принимает «любой объект». Пятнадцать разных форм на одном call site это мегаморфизм. Никакой оптимизаци

— И последнее не стоит использвать условные поля. Та самая makeUser с if (isAdmin). Из одной фабрики выходят две формы. Лучше записать поле с null.

— Всё это про одно. Держи форму стабильной — остальное V8 делает сам.

контракт

Объект — это контракт

your part стабильный shape:
один порядок полей,
без delete

v8's part быстрый offset:
hidden class,
inline cache

mono

→

poly

→

mega

→

dict

[1 мин]

— И теперь то самое, ради чего мы все тут собрались. Пицца! Шучу, главное слово доклада.

— Объект в JS — это контракт. Между вами и V8.

— Ваша часть — стабильная форма. Один порядок полей. Без delete.

— Часть V8 — быстрый offset. Hidden class. Inline cache. Чтение за наносекунду.

— Когда вы нарушаете контракт — то скатываешься по наклонной: monomorphic → polymorphic → megamorphic → dictionary. С каждой ступенью доступ к полю медленнее. С последней ступени можно не вернуться.

— В CRUD-формочках это не заметно. В горячих местах — десятки процентов CPU.

— Node.js быстрый. Просто не мешайте ему.

спасибо

Вопросы?

Бенчи obj-cost

канал zero_deps

Node.js быстрый. Просто не мешайте ему.

Объекты в JS не бесплатные

Василий Каменюк

О чём поговорим

Где быстрее чтение?

Для 99% систем это не нужно

V8 не компилирует.

V8 адаптируется.

Feedback Vector

Объект — это не словарь

Один shape, разные пути

IC: четыре формы — потолок

Same picture? Same picture.

Условное поле - уже две формы

delete — это катастрофа

Guard сорвался — deopt

Как измерял

Сводка · все замеры

V8 11.3 → 12.4: оптимизация ушла

delete уносит в dict mode · ×29

fast path быстрее, dict — ×14

Что же делать?

Объект — это контракт

Вопросы?

`delete` — это катастрофа

`delete` уносит в dict mode · ×29