¿Node.js realmente no optimiza las llamadas a .slice.call (argumentos)?

En los documentos de Bluebird , tienen esto como un anti-patrón que detiene la optimización.

function leaksArguments2() { var args = [].slice.call(arguments); } 

Hago esto todo el tiempo en Node.js. Es esto realmente un problema. Y, si es así, ¿por qué?

Asume solo la última versión de Node.js.

Descargo de responsabilidad: soy el autor de la página wiki

Es un problema si la función que contiene se llama mucho (está caliente). Las funciones que filtran arguments no son compatibles con el comstackdor de optimización (cigüeñal).

Normalmente cuando una función está caliente, será optimizada. Sin embargo, si la función contiene características no admitidas, como la filtración de arguments , ser una función activa no ayuda y continuará ejecutando código genérico lento.

El rendimiento de una función optimizada en comparación con una no optimizada es enorme. Por ejemplo, considere una función que agrega 3 dobles juntos: http://jsperf.com/213213213 21x diferencia.

¿Y si se sumn 6 dobles juntos? En general, cuanto más código tiene la función, más severo es el castigo para que esa función se ejecute en modo no optimizado.

Para node.js, este tipo de cosas en general es realmente un gran problema debido al hecho de que cualquier hora de CPU bloquea completamente el servidor. Simplemente optimizando el analizador de url incluido en el núcleo del nodo (mi módulo es 30 veces más rápido en los propios puntos de referencia del nodo), mejora las solicitudes por segundo de mysql-express de 70K rps a 100K rps en un punto de referencia que consulta una base de datos .

La buena noticia es que el núcleo del nodo es consciente de esto

Es esto realmente un problema

Para el código de aplicación, no. Para casi cualquier módulo / código de biblioteca, no. Para una biblioteca como bluebird que está destinada a ser utilizada de forma generalizada en todo el código base, sí. Si hiciste esto en una función muy caliente en tu aplicación, entonces tal vez sí.

No conozco los detalles, pero confío en que los autores de bluebird sean creíbles porque el acceso a los arguments en las formas descritas en los documentos hace que v8 se niegue a optimizar la función, y es algo que los autores de bluebird consideran que vale la pena usar una macro de tiempo de construcción. para obtener la versión optimizada.

Solo tenga en cuenta los números de latencia que dieron origen al nodo en primer lugar. Si su aplicación hace cosas útiles como hablar con una base de datos o el sistema de archivos, entonces I / O será su cuello de botella y optimizar / almacenar en caché / en paralelo pagará dividendos mucho más altos que las microoptimizaciones en memoria de nivel v8 como las anteriores.