Комментарии 11
НЛО прилетело и опубликовало эту надпись здесь
Это происходит из-за того, что резолв в объекте происходит медленнее, чем просто доступ по ключу.
Не только из-за этого. Автор пишет именно про «для хешей с динамически изменяемым набором ключей», а добавление/удаление ключей в объекте приводит к изменению object shape, что в свою очередь является деоптемизацией.
НЛО прилетело и опубликовало эту надпись здесь
Все диаграммы одинаковы по сути, на первой только полный стек вызовов обработки запроса с множеством вложенных функций, а на последующих — значительно меньший.
Каждый прямоугольник — это функция, ширина которого пропорциональна времени проведенному в этой функции при работе приложения. Соответственно самая широкая нижняя прямоугольник-функция — точка входа. Координата по горизонтали не имеет значения.
Вверх надстраиваются функции вызывающиеся из нижний функции. Т.е. по вертикали показывается вложенность вызовов функций.
Каждый прямоугольник — это функция, ширина которого пропорциональна времени проведенному в этой функции при работе приложения. Соответственно самая широкая нижняя прямоугольник-функция — точка входа. Координата по горизонтали не имеет значения.
Вверх надстраиваются функции вызывающиеся из нижний функции. Т.е. по вертикали показывается вложенность вызовов функций.
Спасибо, за статью, она линий раз демонстрирует, что добиться повышения производительности можно и простым рефакторингом кода, просто времени много надо,
обычно заказчику говорят, Ваш сервер устарел, нужно более мощное оборудование.
Но вот если себе делаешь, то тут конечно можно и попотеть.
Интересно есть ли где нибудь графики скорости работы однотипных функций?
такое могло бы сэкономить кучу времени, так то на уровне подсознания понятно, что простой цикл, с минимумом разименовываний полей будет работать быстрее, но вот насколько и стоит ли игра свеч, так как читаемость кода явно ухудшается.
обычно заказчику говорят, Ваш сервер устарел, нужно более мощное оборудование.
Но вот если себе делаешь, то тут конечно можно и попотеть.
Интересно есть ли где нибудь графики скорости работы однотипных функций?
такое могло бы сэкономить кучу времени, так то на уровне подсознания понятно, что простой цикл, с минимумом разименовываний полей будет работать быстрее, но вот насколько и стоит ли игра свеч, так как читаемость кода явно ухудшается.
На продашен серверах используется node.js версии 6
Очень вовремя вы съехали с версии, которая через уже через 10 дней (30 апреля) перестанет поддерживаться.
Я так понимаю, далее по тексту показываются измерения в 10й версии? Потому что все эти приемчики могут оказаться бесполезными для других версий.
В функции getByUrl после оптимизации вы зачем-то убрали ранний return из цикла, так что код теперь пробегает весь список целиком, даже если совпадение нашлось раньше. Зачем?
i<a.length && !result — эквивалент раннего return-а.
С точки зрения производительности принципиальной разницы с return-ом внутри быть не должно, и насколько помню, такой вариант и появился в процессе проверки этой теории.
В любом случае главное тут замена цикла for..in на обычный for.
С точки зрения производительности принципиальной разницы с return-ом внутри быть не должно, и насколько помню, такой вариант и появился в процессе проверки этой теории.
В любом случае главное тут замена цикла for..in на обычный for.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Оптимизация node.js приложения