/cc @Fishrock123

The total list of issues found:

• lib/_tls_wrap.js:860: var args = normalizeConnectArgs(arguments);
• lib/path.js:195: var paths = Array.prototype.filter.call(arguments, f); Fixed by this PR.
• lib/net.js:58: var args = normalizeConnectArgs(arguments);
• lib/net.js:859: var args = normalizeConnectArgs(arguments);
• lib/dns.js:64: process.nextTick(callMakeAsyncCbNT, callback, arguments);
• lib/console.js:86: var arr = Array.prototype.slice.call(arguments, 1); Fixed by this PR.
• lib/_http_client.js:562: this._deferToConnect('setNoDelay', arguments);
• lib/_http_client.js:565: this._deferToConnect('setKeepAlive', arguments);
• lib/util.js:19: var args = arguments; Fixed by this PR.
• lib/domain.js:239: return intercepted(this, self, cb, arguments); Deprecated
• lib/domain.js:267: return bound(this, self, cb, arguments); Deprecated
• lib/crypto.js:655: return filterDuplicates(getCiphers.call(null, arguments));
• lib/crypto.js:660: return filterDuplicates(getHashes.call(null, arguments));

I'm not sure if fixing most of those matters, but at least some should be fixed imo.

If I get time, I'll run IRHydra against my patch and see what comes out. That would be the best first step, to compare the actual compiled result.

A while back, we had support for macro expansion in our native modules. If this is proving to be a generally viable speedup, it would be nice to put it in macro form so that it's easy to rip out again if V8 changes things.

A comment and a question:

1. al is a terrible name, prefer something like argslen or argc. (argc is terrible too but at least it has a well-understood meaning.)
2. Is there a reason to use var instead of const?

@bnoordhuis

2: Iirc last time we checked const is still slower than var.

If you're referring to the OSR issue, I think I only saw that with let, not const. Also, it was a while ago, it would be good to retest.

this jsperf shows that const is faster than var right now

@Fishrock123, @bnoordhuis Compound assignment deoptimizes let: let x = 10; x += 1; is slow in both 4.2 and 4.3, but let x = 10; x = x + 1; is fine. This shouldn't be an issue for const because you don't want compound assigments with const =).

@bnoordhuis Done:

• assert is now cached;
• al got renamed to argsleft because that's the number of not yet processed/copied arguments;
• arr and paths are now const.

@brendanashworth Ow. That jsperf shows that var is faster than const right in Chromium 43.
Will test in iojs + 4.2 and iojs + 4.3 in a moment.
Edit: I would say that there is no difference between var and const performance for the testcase supplied above (as the jsperf link) in iojs + 4.2 or 4.3.

We should probably move to preferring const (where correct/possible) in all new patches then.

LGTM

Should I patch other places from #1752 (comment) ?

@ChALkeR yes please :)

The let performance patch landed in v8 4.4.30.

I'd be a lot more comfortable with this if it were reintroduced as a macro. It'd be a lot easier to document / spread knowledge about its use, as well as to back out of it if perf characteristics change.

@chrisdickinson This is a temporary solution anyways.
The proper way would be using rest params.

Related: https://code.google.com/p/v8/issues/detail?id=2159
Once this is properly implemented and optimized (as it should be), it should be used instead of arguments and copy-arguments-into-an-array methods.

A macro (and documenting it) seems like a bit undue for a temporary hack.

@ChALkeR In my experience rest params are already almost on par with using arguments. It's the spread operator that will eat your face.

@trevnorris arguments is not an array, also it introduces a deopt if you do anything to it except taking arguments.length (in fact this also should be done carefully) and accessing arguments[i] where 0 <= i < arguments.length. This is why manually copying arguments to an array and passing that array is faster than passing the arguments object.

«On par with arguments» is not good enough. Afaik, rest params are deoptimized (or, rather, not yet optimized) for now. Also, I am not sure what is the v8 version requirements for them to work without issues. And they are behind a flag.

See https://github.com/petkaantonov/bluebird/wiki/Optimization-killers#3-managing-arguments.

@ChALkeR I'm aware of all that. Was just stating that rest params being well optimized isn't far off.

@trevnorris Yes. And that's why I don't see an advantage in hacking this with something more complex, as macro (and documenting it), as @chrisdickinson proposed here: #1752 (comment)

@ChALkeR @trevnorris ... what's the status on this?

@jasnell I need to re-apply this (some places mentioned in the above list were already fixed by other patches), and then re-test to see if there is any actual improvement with the current v8 version in master.

Closing, obsolete. See #4361, also current master has rest parameters enabled by default, perhaps this should be redone using those.