Комментарии 17
Чрезвычайно любопытно. В большинстве случаев это конечно станет экономией на спичках, но я определённо учту и в собственном коде и при проведении ревью
Да, это "экономия на спичках", но в случае JavaScript этих "спичек" очень много :)
Вот ещё одна такая "спичка": при сдвиге индексации на единицу код может стать в 15 раз быстрее.
fast by default
чтобы был профит от описанной оптимизации, изначальный код должен создавать тысячи объектов, и не классов, а литералов, причем с разным порядком большинства свойств. по-моему это редкость.
и не будем забывать, что в будущих версиях V8 эта оптимизация может перестать работать, а «некрасивый» код так и будет мозолить глаза. :)
и еще, влияет ли эта оптимизация на скорость доступа к свойствам объекта после его создания?
Это очень важная и полезная оптимизация на долгоживущих spa приложениях или мобильных версиях (каждый новый объект с новой структурой увеличивает расход памяти на "внутреннее" представление) или серверных приложениях
чтобы был профит от описанной оптимизации, изначальный код должен создавать тысячи объектов, и не классов, а литералов, причем с разным порядком большинства свойств. по-моему это редкость
Это вполне возможно. Самый часто распространенный сценарий: любая функция, принимающая в качестве аргумента объект:
helper({param1: 1, param2: 2})Это ведь тоже объект, который нужно создать перед передачей в функцию. И такие однотипные объекты-аргументы создаются при каждом вызове функции helper.
влияет ли эта оптимизация на скорость доступа к свойствам объекта после его создания?
Влияет. См. параграф "Встроенные кэши"
Судя по тому, что в мире JS никто не обсуждает влияние и механизмы GC, то всем пока не до производительности. Ибо в тех же Java и C# понимание GC одна из важнейших вещей.
Судя по тому, что в мире JS никто не обсуждает влияние и механизмы GC
Это не так. Есть много материалов на эту тему. За примером далеко ходить не нужно: управление памятью, четыре вида утечек памяти и борьба с ними. Тут скорее дело в другом. Начиная работать с JS ты можешь не думать или не понимать как работает GC. Но с ростом начнешь этим интересоваться. И хотя прямого управления сборкой мусора у тебя нет, я считаю очень важным понимать как твой код будет на неё влиять.
Все это работает и актуально для количества свойств примерно больше 7 (зависит от версии v8). До <= 7 свойства хранятся напрямую в объекте, имеют максимальную скорость к ним доступа и не подвержены снижению производительности из-за порядка
v8.dev/blog/fast-properties#the-three-different-kinds-of-named-properties
Как вам такая философия? В условиях экономики например, РФ, спрос падает, кол-во заказов, а соответственно, количество интерактива пользователей снижается, поэтому, оптимизацией заниматься смысла нет. Коду, написанному сейчас, будет предоставлено все больше и больше времени на выполнение в будущем.
Насколько важен порядок свойств в объектах JavaScript?