В документах bluebird они имеют это как анти-шаблон, который останавливает оптимизацию.. Они называют это аргументом утечки,
function leaksArguments2() {
var args = [].slice.call(arguments);
}
Я делаю это все время в Node.js. Это действительно проблема. И если да, то почему?
Предположим, что только последняя версия Node.js.
Отказ от ответственности: я являюсь автором вики-страницы
Это проблема, если содержащая функция называется много (она горячая). Функции, которые утечки arguments не поддерживаются оптимизирующим компилятором (коленчатым валом).
Обычно, когда функция горячая, она будет оптимизирована. Однако если функция содержит неподдерживаемые функции, такие как утечка arguments, то горячая функция не помогает, и она будет продолжать работать с медленным общим кодом.
Производительность оптимизированной функции по сравнению с неоптимизированной является огромной. Например, рассмотрим функцию, которая добавляет 3 удвоения вместе: http://jsperf.com/213213213 разница в 21 раз.
Что, если он добавит 6 парных? 29x разница Как правило, чем больше кода имеет функция, тем более суровым является наказание за выполнение этой функции в неоптимизированном режиме.
Для node.js таких вещей вообще является на самом деле огромной проблемой из-за того, что любое время процессора полностью блокирует сервер. Просто оптимизируя парсер URL-адресов, который включен в ядро node (мой модуль на 30 раз быстрее в node собственных тестах), улучшает количество запросов в секунду mysql- экспресс с 70 Кбит/с до 100 Кбит/с в тесте, который запрашивает базу данных.
Хорошей новостью является то, что ядро node знает об этом
Это действительно проблема
Для кода приложения нет. Для почти любого модуля/библиотечного кода нет. Для библиотеки, такой как bluebird, которая предназначена для использования повсеместно во всей кодовой базе, да. Если вы сделали это в очень горячей функции в своем приложении, то, возможно, да.
Я не знаю подробностей, но я уверен, что авторы bluebird заслуживают доверия, поскольку доступ к arguments способами, описанными в документах, приводит к тому, что v8 отказывается оптимизировать функцию, и, следовательно, это то, что авторы синих птиц считают целесообразным использовать макрос времени сборки для получения оптимизированной версии.
Просто имейте в виду номера латентности, которые привели к node в первую очередь. Если ваше приложение действительно использует такие вещи, как разговор с базой данных или файловой системой, то вы будете "узким местом", а оптимизация/кэширование/распараллеливание будут платить гораздо более высокие дивиденды, чем микро-оптимизации оптимизации на уровне v8, такие как выше.