SWC

У нас на проекте несколько сотен тысяч строк кода в монорепе, разбросанных по десяткам пакетов. Крупнейший сервис (админка) собирается на M1 с бабелем секунд 80 (после установки нод модулей). Мой коллега @Astartsky решил поправить перф сборки и попробовать SWC.

Миграция с бабеля оказалась практически безболезненной, тк SWC сразу включает в себя множество фич, которые реализованы в бабеле плагинами. Меньше чем за день удалось все завести и ускорить сборку до…

Скольки вы думаете?)

10 секунд, ускорение в ~8 раз. Для нас это значительная разница и результат очень обрадовал.

Паблишь в прод тормозят только небольшие проблемы в дев сборке со styled-components. Которые не будут решены, но решаются частично, да и чем-то можно пожертвовать ради такого перфа.

Через минут 5 войс про перф оптимизацию, которую я долго искал и когда нашел ужаснулся

Качество звука не очень, я завтра ещё текстом подробно опишу.

Всем хороших выходных

Профилирование производительности

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

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

План был такой: посмотреть в профайлер от квоки, увидеть прожорливое место в коде и исправить ошибку, которую я, видимо, не заметил раньше.

По факту все было дольше и вот почему:

1) Из стандартного отсортированного списка вызовов функций я ничего понять не смог. Пошел изучал флеймграф. Там тоже мало что понятно, пока не не схлопнешь одинаковые вызовы вместе (Toggle left-heavy view).
2) В бенче происходило много лишней работы, кроме самого теста реатома, которая мусорила в результаты. Для удобства чтения я закомментировал не важный для анализа код.
3) Когда я нашел прожорливое место перейти в исходники мне не удалось, видимо сурсмапы не подтягивались. Понимать минифицированный код было очень сложно, а преттиер не хотел его форматировать из-за какой-то ошибки парсинга. К счастью, у меня был установлен Rome и он смог отформатировать код к более понятному состоянию.
4) Я перезапустил профайлер и переоткрыл флеймграф, но ссылка на функцию потребляющую много ресурсов все еще вела на первую строчку, как будто код все еще минифицирован. Помогло только rm /Users/artalar/.quokka/test.cpuprofile
5) Дальше меня ждал большой сюрприз, функция которая потребляля треть перфа в большом пайплайне операций была очень тривиальной и я все никак не мог понять в чем там проблема. Тк. профилировщик дает ссылку не на конкрутную проблемную операцию, а на содержащую ее функцию, я решил разбить внутрении операции на отдельные функции, а для удобочитаемости минифицированного кода я переписал функцию на методы тестового объекта - минификатор не меняет имена свойств, только переменные.
6) Повторяем п. 4 и вуаля! Проблема найдена. В минифицированной версии спред заменялся на свою реализацию с Object.assign (или полифилом).

Осталось лишь переписать копирование объекта на ручной перебор всех свойств и флеймграф стал более равномерным, ура-ура!)

P.S. Я попробовал запустить бенч с импортом из исходников, а не билда, для нормальной работы сурсмапов, но сами результаты тестов в этом случае едут (терсер и другие минификаторы делают некоторые AOT улучшения кода), да и ссылки все равно были на транспилированную версию без типов, которую делает квока под каптом.
P.P.S. После смены таргета билда на современные браузеры спред не транспилируется и работает быстрее, но версия с ручным перебором свойств все равно заметно быстрее.

Есть такой уже старый и почти заброшенный ponyfoo.com, которым я восторгался в свое время. Там можно найти множество глубоких и понятных статей по теме фронтенда и далеко не все из них уже устарели.

Например, туда писал Benedikt Meurer, один из разработчиков v8.

Или вот еще пара статей:
Polyfills or Ponyfills?
The JavaScript Standard

А по поводу проблем с производительностью спред оператора есть такие баги:

https://bugs.chromium.org/p/v8/issues/detail?id=10763

https://bugs.chromium.org/p/chromium/issues/detail?id=1204540

Выдержка от @cevek:

видимо проблема в том что спред создает новый объект не соответветсвующей мапе к оригинальному

The problem is that the CloneObjectIC creates local copies of object literal maps instead of reusing the shared trees from the cache. The following should be true but isn't:

 ~/v8$ v8 --allow-natives-syntax  --nolazy-feedback-allocation
 d8> o = {a:1, b:2}; %HaveSameMap({...o}, {...o})
 false

от этого случается мегаморфизм и прощай перформанс

Го войс на свободную тему минут через 5

Про легаси компоненты реакта, тестирование компонентов, конкурентные очереди в вебе и закрытые камьюнити