Оптимизация node.js приложения

[@Odrin]

Это происходит из-за того, что резолв в объекте происходит медленнее, чем просто доступ по ключу.

Не только из-за этого. Автор пишет именно про «для хешей с динамически изменяемым набором ключей», а добавление/удаление ключей в объекте приводит к изменению object shape, что в свою очередь является деоптемизацией.

[@sh84]

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

[@1c80]

Спасибо, за статью, она линий раз демонстрирует, что добиться повышения производительности можно и простым рефакторингом кода, просто времени много надо,
обычно заказчику говорят, Ваш сервер устарел, нужно более мощное оборудование.
Но вот если себе делаешь, то тут конечно можно и попотеть.
Интересно есть ли где нибудь графики скорости работы однотипных функций?
такое могло бы сэкономить кучу времени, так то на уровне подсознания понятно, что простой цикл, с минимумом разименовываний полей будет работать быстрее, но вот насколько и стоит ли игра свеч, так как читаемость кода явно ухудшается.

[@justboris]

На продашен серверах используется node.js версии 6

Очень вовремя вы съехали с версии, которая через уже через 10 дней (30 апреля) перестанет поддерживаться.

Я так понимаю, далее по тексту показываются измерения в 10й версии? Потому что все эти приемчики могут оказаться бесполезными для других версий.

[@sh84]

Да, все в 10й.

[@justboris]

В функции getByUrl после оптимизации вы зачем-то убрали ранний return из цикла, так что код теперь пробегает весь список целиком, даже если совпадение нашлось раньше. Зачем?

[@sh84]

i<a.length && !result — эквивалент раннего return-а.
С точки зрения производительности принципиальной разницы с return-ом внутри быть не должно, и насколько помню, такой вариант и появился в процессе проверки этой теории.
В любом случае главное тут замена цикла for..in на обычный for.

[@justboris]

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

если нет, то я бы оставил return, потому что оптимизации оптимизациями, но и понятность кода важна тоже.

[@sh84]

Прироста нет.
Пусть остается как есть, что бы было понятно очем мы говорили.
Комментарий про то, что смысл правки в другом виде цикла я добавил.