Comments 8
Всем, кому хочется кровавых деталей, я советую во всех отношениях чудесный доклад Вячеслава Егорова — Производительность JavaScript через подзорную трубу
Прекрасный доклад. Очень доходчиво и ясно объясняет, почему нельзя просто взять и сунуть код в цикл и измерить производительность. Хотя после доклада я совсем не знаю как можно более-менее точно сравнить производительность кроме как по временной сложности алгоритма.
Практически все приведённые автором примеры жестоко-контринтуитивного поведения — это банально следствия багов в V8, которые давно уже исправлены.
А там, где багов нет, поведение JIT более или менее предсказуемо. Да, есть много нюансов, как впрочем и везде. Но в целом предположения о перфомансе, основанные на классических теориях, обычно работают даже в JS.
А там, где нормальные оптимизации — они более-менее предсказуемы и их более-менее возможно учесть. Если знать базовую теорию, конечно. Ну камон, удаление мертвого кода, развёртку циклов или распространение констант придумали лет 40 назад, если не больше.
Проблема с бенчмаркингом js заключается в том, что ты никогда не знаешь, что именно оптимизировал компилятор — твой код или (гораздо более вероятно) комбинацию твоего кода и твоего бенчмарка
Всегда можно совершенно точно узнать что наоптимизировал компилятор, достаточно посмотреть ассемблерный код в который компилируется js (через комманду node --print-opt-code --code-comments code.js) и там легко увидеть (по call инструкциям и комментариям) что заинлайнилось а что нет, либо есть инструмент для визуального отображения различных оптимизаций v8 — Turbolizer (оригинальный репозиторий тут а описание и онлайн-версию можно найти тут). А для того чтобы код бенчмарка не влиял на производительность тестируемого кода то можно не мерять производительность а просто прогнать оптимизации для конкретной функции и посмотреть на то что и как инлайнится и для этого просто нужную функцию вызываем через специальную встроенную глобальную функцию %OptimizeFunctionOnNextCall(fn) (которая будет доступна после запуска ноды с флагом node --allow-natives-syntax code.js)
Ну а после того как вы убедились что нужный код заинлайнен в инструкции ассемблера (а иначе он наверняка будет работать медленно так как v8 на текущий момент научился инлайнить очень многое — не только различные циклы, но и методы работы с массивами — всякие .map(), .filter(), .find(), а также создание объектов и функций) то дальше можно совершенно точно (вплоть до тактов) предсказать время работы кода — достаточно понять как работают кеши процессора (https://www.youtube.com/watch?v=JU_RAcsfQVs), немного про то как работает виртуальная память (https://www.youtube.com/watch?v=dFquxC6qTSA) ну и конечно же дока по процессору (https://software.intel.com/en-us/articles/intel-sdm) где с точностью до тактов расписано время работы каждой ассемблерной инструкции
Вместо того чтобы строить догадки о том, какая именно часть кода работает медленно, лучше будет выяснить это, воспользовавшись вышеописанными методиками.
Рискну прослыть капитаном — но выяснять, какая часть кода работает медленно, нужно с помощью профайлера. Иначе — удачи с добавлением time / timeEnd по всей кодовой базе (и да, все равно тормоза рендеринга, который зачастую инициируется фрейворком, а не вашим кодом, не будут видны таким образом)
Измерение производительности JavaScript-функций