Удалёнка: опыт и лайфхаки
Реклама
Комментарии 17
+2

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

0

Да, это "экономия на спичках", но в случае JavaScript этих "спичек" очень много :)

0

Вот ещё одна такая "спичка": при сдвиге индексации на единицу код может стать в 15 раз быстрее.
fast by default

НЛО прилетело и опубликовало эту надпись здесь
+2

Если реально заморачиваться такой оптимизацией, то без инструмента статического анализа здесь не обойтись. Вручную уследить за порядком инициализации свойств нереально.


Однако маловероятно, что кто-то откажется от мержа объектов с помощью spread operator из-за нарушения порядка полей.

+3
жаль, что сделать замер в реальном приложении, а не синтетическом тесте, слишком сложно. я вот не уверен, что будет заметный прирост. может быть овчинка выделки не стоит.

чтобы был профит от описанной оптимизации, изначальный код должен создавать тысячи объектов, и не классов, а литералов, причем с разным порядком большинства свойств. по-моему это редкость.

и не будем забывать, что в будущих версиях V8 эта оптимизация может перестать работать, а «некрасивый» код так и будет мозолить глаза. :)

и еще, влияет ли эта оптимизация на скорость доступа к свойствам объекта после его создания?
-1

Это очень важная и полезная оптимизация на долгоживущих spa приложениях или мобильных версиях (каждый новый объект с новой структурой увеличивает расход памяти на "внутреннее" представление) или серверных приложениях

+1
чтобы был профит от описанной оптимизации, изначальный код должен создавать тысячи объектов, и не классов, а литералов, причем с разным порядком большинства свойств. по-моему это редкость

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


helper({param1: 1, param2: 2})

Это ведь тоже объект, который нужно создать перед передачей в функцию. И такие однотипные объекты-аргументы создаются при каждом вызове функции helper.


влияет ли эта оптимизация на скорость доступа к свойствам объекта после его создания?

Влияет. См. параграф "Встроенные кэши"

0
влияет ли эта оптимизация на скорость доступа к свойствам объекта после его создания?

Влияет. См. параграф «Встроенные кэши»

ага, вот это уже интереснее
+2

Судя по тому, что в мире JS никто не обсуждает влияние и механизмы GC, то всем пока не до производительности. Ибо в тех же Java и C# понимание GC одна из важнейших вещей.

+4
Проблема в том, что реализации GC могут отличаться от браузера к браузеру. А возможности с GC взаимодействовать программно практически нет (только в ноде под флагом --expose_gc). Любой разработчик должен понимать механизмы и влияние GC, это само собой разумеющееся. Но именно обсуждать в разрезе JS фактически нечего.
+1
Судя по тому, что в мире JS никто не обсуждает влияние и механизмы GC

Это не так. Есть много материалов на эту тему. За примером далеко ходить не нужно: управление памятью, четыре вида утечек памяти и борьба с ними. Тут скорее дело в другом. Начиная работать с JS ты можешь не думать или не понимать как работает GC. Но с ростом начнешь этим интересоваться. И хотя прямого управления сборкой мусора у тебя нет, я считаю очень важным понимать как твой код будет на неё влиять.

+3
Небольшое уточнение:

Все это работает и актуально для количества свойств примерно больше 7 (зависит от версии v8). До <= 7 свойства хранятся напрямую в объекте, имеют максимальную скорость к ним доступа и не подвержены снижению производительности из-за порядка

v8.dev/blog/fast-properties#the-three-different-kinds-of-named-properties
0
The number of in-object properties is predetermined by the initial size of the object. If more properties get added than there is space in the object, they are stored in the properties store
0

Я так и подумал :) Просто сделал сноску для следующего читателя.

-1

Как вам такая философия? В условиях экономики например, РФ, спрос падает, кол-во заказов, а соответственно, количество интерактива пользователей снижается, поэтому, оптимизацией заниматься смысла нет. Коду, написанному сейчас, будет предоставлено все больше и больше времени на выполнение в будущем.

Только полноправные пользователи могут оставлять комментарии.  , пожалуйста.