Как стать автором
Обновить
15
0
Александр Шуваев @sh84

Пользователь

Отправить сообщение
Если посмотреть в top-е на запущенное в 1 воркер node приложение, можно увидеть кучку дополнительных потоков. Как минимум в отдельном потоке/потоках работает GC.
Я, например, наблюдал максимум 120% нагрузку CPU от 1 инстанса node сервера.
Прироста нет.
Пусть остается как есть, что бы было понятно очем мы говорили.
Комментарий про то, что смысл правки в другом виде цикла я добавил.
i<a.length && !result — эквивалент раннего return-а.
С точки зрения производительности принципиальной разницы с return-ом внутри быть не должно, и насколько помню, такой вариант и появился в процессе проверки этой теории.
В любом случае главное тут замена цикла for..in на обычный for.
Да, все в 10й.
Все диаграммы одинаковы по сути, на первой только полный стек вызовов обработки запроса с множеством вложенных функций, а на последующих — значительно меньший.
Каждый прямоугольник — это функция, ширина которого пропорциональна времени проведенному в этой функции при работе приложения. Соответственно самая широкая нижняя прямоугольник-функция — точка входа. Координата по горизонтали не имеет значения.
Вверх надстраиваются функции вызывающиеся из нижний функции. Т.е. по вертикали показывается вложенность вызовов функций.
То сам себе злобный буратино :)
Защита от подобного — отдельная история, и врят ли нужна для устройства к которому есть непосредственный доступ, а правки происходят в ручном режиме.
Замечу, что в разбери встроен аппаратный ватчдог, и его можно настроить так, что зависание или падение вашей программы будет приводить к ребуту.
И все это уже произошло. В прошлом году.
Фактически речь идет о фиксации уже поддерживаемого всеми основными браузерами решения.
Да, linux. Имхо на всех *nix сравнительная производительность останется неизменной.
Спасибо, добавил.

Информация

В рейтинге
Не участвует
Откуда
Орловская обл., Россия
Зарегистрирован
Активность