CODEWITHSUNDEEP
node.jsoptimization
Evan Carroll
Evan Carroll

Reputation: 1

Does node.js really not optimize calls to [].slice.call(arguments)?

In the bluebird docs, they have this as an anti-pattern that stops optimization.. They call it argument leaking,

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

I do this all the time in Node.js. Is this really a problem. And, if so, why?

Assume only the latest version of Node.js.

Upvotes: 13

Views: 1630

Answers (2)

Esailija
Esailija

Reputation: 140230

Disclaimer: I am the author of the wiki page

It's a problem if the containing function is called a lot (being hot). Functions that leak arguments are not supported by the optimizing compiler (crankshaft).

Normally when a function is hot, it will be optimized. However if the function contains unsupported features like leaking arguments, being a hot function doesn't help and it will continue running slow generic code.

The performance of an optimized function compared to an unoptimized one is huge. For example consider a function that adds 3 doubles together: http://jsperf.com/213213213 21x difference.

What if it added 6 doubles together? 29x difference Generally the more code the function has, the more severe the punishment is for that function to run in unoptimized mode.

For node.js stuff like this in general is actually a huge problem due to the fact that any cpu time completely blocks the server. Just by optimizing the url parser that is included in node core (my module is 30x faster in node's own benchmarks), improves the requests per second of mysql-express from 70K rps to 100K rps in a benchmark that queries a database.

Good news is that node core is aware of this

Upvotes: 13

Peter Lyons
Peter Lyons

Reputation: 146064

Is this really a problem

For application code, no. For almost any module/library code, no. For a library such as bluebird that is intended to be used pervasively throughout an entire codebase, yes. If you did this in a very hot function in your application, then maybe yes.

I don't know the details but I trust the bluebird authors as credible that accessing arguments in the ways described in the docs causes v8 to refuse to optimize the function, and thus it's something that the bluebird authors consider worth using a build-time macro to get the optimized version.

Just keep in mind the latency numbers that gave rise to node in the first place. If your application does useful things like talking to a database or the filesystem, then I/O will be your bottleneck and optimizing/caching/parallelizing those will pay vastly higher dividends than v8-level in-memory micro-optimizations such as above.

Upvotes: -2

Related Questions