does node js really not optimize calls to slice callarguments

does node js really not optimize calls to slice callarguments  using -'node.js,optimization'

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

function leaksArguments2() {
    var args = [];

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.

asked Sep 22, 2015 by abhimca2006
0 votes
1 view

2 Answers

0 votes

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: 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

answered Sep 22, 2015 by tejas lakhani
0 votes

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.

answered Sep 22, 2015 by mca.agarwal