Оптимизация Node.JS приложения
https://m.habr.com/ru/post/414541/
Вжуууух и ускоряем приложение на Node.JS. Параллельно замеряем, смотрим - где, что и сколько выполняется.
Спойлер - в первую очередь обновитесь до последней версии ноды. Приложение у вас не сломается(потому что в исходниках ноды запариваются об обратной совместимости), но станет быстрее - возможно от 10% до нескольких раз
Fun story:
Был у меня как-то скрипт на ноде - там по сути надо было правильно заполнить Excel таблицу. То есть: собрать данные с разных мест, соотнести эти данные с правильной строкой в таблице и заполнить недостающие данные.
И внутри него у меня было 2 массива по 200 строк данных - я сначала тупо написал цикл, который проходится по массиву и находит нужную строку из таблицы. Там была одна особенность в коде - для удобства maintain-a этого кода я решил отделить код вставки данных в новую таблицу от всего остального кода. Так как у каждой колонки была своя логика заполнения данных, то я пришел к выводу, что один файл с кодом(модуль) - это то, как заполнять именно эту колонку в табличке. Много колонок - много модулей, если нет модуля заполняющая эту колонку - значит ее еще не заимплементили. Тогда люди всегда будут понимать, как вообще эта табличка заполняется и что именно заполняется в этой табличке.
Проблема: теперь у меня не 200 вызовов функции поиска строки, a NumberOfRows * NumberOfColumns вызовов. Ну, я такой думаю: все время делать поиск по массиву - это очень долго(обычный цикл, О(n^2) на время исполнение), давай уж перепишу на HashMap - буду стучаться по ключу и поиск будет занимать О(1).
Тужился-пыжился, за 2 часа написал код на HashMap, был горд и доволен собой - пока не решил посмотреть время исполнения кода. Оно просто не отличалось. Естественно я негодую, расчехлил тулзу для генерации Flamegraph моего приложения, погонял старый и новый код через него. Выяснилось, что с самого начала мой код на циклах изначально занимал мало времени всего кода - разрабы Node.js и V8 видимо поняли,что если массив не меняется, то результат выборки по массиву можно мемоизировать - по сути это тот же самый HashMap как in-memory cache(ключ - входные параметры функции, значение - результат этой функции), следовательно O(1) на поиск.
Кароч, теперь никогда не начну оптимизацию кода без предварительного профайлинга и выяснения где именно медленно. А то опять потрачу многие часы на бесполезную фигню
https://m.habr.com/ru/post/414541/
Вжуууух и ускоряем приложение на Node.JS. Параллельно замеряем, смотрим - где, что и сколько выполняется.
Спойлер - в первую очередь обновитесь до последней версии ноды. Приложение у вас не сломается(потому что в исходниках ноды запариваются об обратной совместимости), но станет быстрее - возможно от 10% до нескольких раз
Fun story:
Был у меня как-то скрипт на ноде - там по сути надо было правильно заполнить Excel таблицу. То есть: собрать данные с разных мест, соотнести эти данные с правильной строкой в таблице и заполнить недостающие данные.
И внутри него у меня было 2 массива по 200 строк данных - я сначала тупо написал цикл, который проходится по массиву и находит нужную строку из таблицы. Там была одна особенность в коде - для удобства maintain-a этого кода я решил отделить код вставки данных в новую таблицу от всего остального кода. Так как у каждой колонки была своя логика заполнения данных, то я пришел к выводу, что один файл с кодом(модуль) - это то, как заполнять именно эту колонку в табличке. Много колонок - много модулей, если нет модуля заполняющая эту колонку - значит ее еще не заимплементили. Тогда люди всегда будут понимать, как вообще эта табличка заполняется и что именно заполняется в этой табличке.
Проблема: теперь у меня не 200 вызовов функции поиска строки, a NumberOfRows * NumberOfColumns вызовов. Ну, я такой думаю: все время делать поиск по массиву - это очень долго(обычный цикл, О(n^2) на время исполнение), давай уж перепишу на HashMap - буду стучаться по ключу и поиск будет занимать О(1).
Тужился-пыжился, за 2 часа написал код на HashMap, был горд и доволен собой - пока не решил посмотреть время исполнения кода. Оно просто не отличалось. Естественно я негодую, расчехлил тулзу для генерации Flamegraph моего приложения, погонял старый и новый код через него. Выяснилось, что с самого начала мой код на циклах изначально занимал мало времени всего кода - разрабы Node.js и V8 видимо поняли,что если массив не меняется, то результат выборки по массиву можно мемоизировать - по сути это тот же самый HashMap как in-memory cache(ключ - входные параметры функции, значение - результат этой функции), следовательно O(1) на поиск.
Кароч, теперь никогда не начну оптимизацию кода без предварительного профайлинга и выяснения где именно медленно. А то опять потрачу многие часы на бесполезную фигню