Хабр Курсы для бэкендеров
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Поток Бэкенд доступен 24/7 благодаря поддержке друзей Хабра
Комментарии 23
Как я понимаю, если использовать class, описывать в нем явно все поля и т п, то все эти оптимизации будут из коробки?
Почти. Явно объявленные поля класса дают экземплярам один стабильный shape, и V8 сможет использовать быстрый доступ. Этом в целом и все, если поля удалять, добавлять деоптимизация придет, так же как и с обычным объектом
По идее нет. В классе же порядок полей не специфицируется. Декларация полей есть только в TypeScript. С конструктором, кстати, интересно: будет ли последовательная инициализация this.a = ...; this.b = ...; this.c = ...; порождать отдельные скрытые классы, или в случае линейного кода V8 догадается это оптимизировать?
При this.a = ...; this.b = ...; this.c = ...; V8 проходит через промежуточные формы по дереву переходов, но переиспользует их. Поэтому все экземпляры в итоге получают одну финальную форму.
А поля класса инициализируются в порядке объявления, поэтому форма экземпляров будет стабильной.
Если отвалились почки, то поздно пить боржоми. Стоит ли сейчас копаться в особенностях кода у JS? Все проблемы с JS уже решаются при помощи ИИ. Я ничего не смыслю в программировании, но недавно написал пару программ (JS в формате HTML, 1000...1500 строк кода). Работают в любом браузере и быстро обрабатывают многомиллионные массивы данных, представляя их в графическом формате (Plotly.js). Использовал несколько бесплатных ИИ. Иногда неплохо справлялись китайские. GigaChat для подобных задач явно ещё не созрел. Очень неплохо проявил себя Gemini. ChatGpt долго пудрил мозги, но код писать не стал. А вот к Claude (Sonnet 5) претензий нет. Он блестяще справился со всеми задачами. Правда, из-за лимитов бесплатного доступа пришлось обращаться к нему несколько раз. Хорошо, что мне торопиться некуда.
Ваш пример как раз показывает, что ИИ сильно снизил порог входа, и это прекрасно. Но он помог решить конкретную прикладную задачу. Это ещё не значит, что знание языка и рантайма стало ненужным. Вы сформулировали требования, сравнили модели, провели несколько итераций и проверили результат. Клод написал код, но постановщиком, тестировщиком и экспертом в предметной области остались вы.
Копаться в устройстве V8 действительно нужно не каждому. Я не вижу ничего плохого в использовании ИИ-болванов от разных производителей при решении задач. Наоборот, только за: они здорово помогают в работе и исследованиях. Только замечу, что оптимальный код они пишут далеко не всегда.
Когда от кода требуется укладываться в бюджет CPU и памяти и держать SLA с нужным количеством девяток, без экспертизы будет сложновато даже с фронтирными моделями. Если не знать, куда направить модель, сама она туда может и не пойти.
Я ничего не смыслю в программировании
Тогда на кой вы пришли в комментарии сюда
Смею предположить, что если если во фразе “Все проблемы с JS уже решаются при помощи ИИ. Я ничего не смыслю в программировании”, между “JS” и “уже”, поставить недостающую часть ", что мне известны, ", то результат будет очевиднее. Иначе непонятно, какие именно “все”, кем, зачем и для чего они решаются.
Столько букв и ни слова про Object.create(), который создаёт реально пустой объект, не наследуя мусор.
Да и сори пост выглядит нейрослопно
Да, Object.create(null) стоило упомянуть. Он действительно создаёт объект без прототипа, но на уровне V8 это не «реально пустой» объект: он сразу создаётся в dictionary mode. В моём бенчмарке на Node 20/22/24 создание такого объекта с тремя полями примерно в 6 раз медленнее литерала {}. Поэтому от описанных в статье проблем он не спасает, а фактически сразу выбирает slow path. Для словаря без унаследованных свойств вещь полезная, но обычные объекты им заменять точно не стоит.
Ты и для комментариев ии юзаешь?)) Не надо так)
А еще этот же ии, я на митап выступать отправил)
Ну нет предела ереси агентной, таково время.
Рассмотрите в качестве бенчмарка проход по ключам, аля словари, добавление ключей и так далее. Там будет процентов 10%+ у object.create. Map за рамками, но понятно еще быстрее. Мы же их для чего-то создаем, а не просто так))
Вот тут V8 уже не прощает.
deleteпереводит объект в dictionary mode (он же slow mode, normalized properties). Это hashmap вместо фиксированного layout. Ни inline cache, ни офсетов, каждое чтение поля идёт через hash lookup в C++ runtime. И обратно V8 объект уже не вернёт, даже если форма стабилизировалась.
да да, вот что бы у вас хешмепа была, и подойдет object.create. Короче помощнее ИИшку найдите))
п.c. воть, и удаление быстрее!)
А на какой версии ноды? И как замеряли?
Есть момент аллокации пустого .create, аллоцируется объект, но его property store хеш, а не массив. Это валидно для V8, ну и может в стандарте так. Смотри просто доклады инженеров V8, а не слушай нейронку. Benedikt Meurer например пару докладов прикольных делал, с юморком
Мы как будто про разное. Я в статье и бенчах, про стоимость доступа к известном полю при разных формах объекта.
Вы же про совсем другой сценарий.
Подскажите, мне для моей ии, на какой версии ноды замеры на скрине? Я пока буду смотреть доклады инженеров V8, бенчмарки погоняю, померяю. Может пойму что-нибудь)
И в целом спасибо, что дали тему для новой статьи)
Ну вы delete упоминали? Цитата выше? Да, с очень поверхностными и на половину верными утверждениями. Про бесплатность и скобок {}, прямо в заголовке. Но ноль про namedictionary, object.create и прочее.
То есть вы не владеете и не понимаете тему, но пушите пост, ходите там на какие то митапы выступать. Даже этот вопрос про версию ноды. Это фундамент V8 с первой версии. Берите любую.
про стоимость доступа к известном полю
Опять же в ряде случаев .create будет лучше, особенно если доступ к несуществующему. {} c прототипом пойдет проверять цепочку.
Ну зачем так сразу, бросаться "не владеете темой".
Я не учебник по V8 принёс. Статья про конкретный сценарий: стоимость доступа к известному полю при стабильной и нестабильной форме объекта.
Все ваши аргументы, интересны, правильны и достойны внимания, но сценарий другой.
Стандарт гарантирует только null в прототипе. А вот реализация зависит от версии движка. Поэтому вопрос про версию nodejs и V8, считаю базовым при любой разговоре про бенчмарки и производительность.
Даже за примером далеко не надо ходить, у меня в бенчах, V8 11.3 удаление последнего добавленного поля оставляет объект в fast properties. А вот 12.4 и 13.6 уже сваливает обьект в dictionary mode.
Поэтому «берите любую версию» для бенчмарка не работает.
Так вот какая версия в ваших замерах выше? Мне так, для моего ии.
И да, буду рад прочитать ваш материал про namedictionary, .create, и каким образом это влияет на скорость доступа к известному полю.
По моим замерам доступа к известному полю на разных версиях ноды, обьект без прототипа уступает
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Объекты в JS не бесплатные