spread op shouldn't slice arguments

[kaaaahhhhnnnn]

Using the spread op in an ES6 function:

function foo(...args){

compiles to something like:

function foo(args){
    args = [].slice.call(arguments, 0);
}

This leaks and prevents compiler optimization (There's about a 20x slowdown here). As much as I dislike code bloating, I believe it should compile to:

function foo(args){
    args=[];
    for(var i=0, l=arguments.length; i<l; i++){ args.push(arguments[i])); }
}

or similiar (obviously slightly different if the spread isn't the first argument).

[MatrixFrog]

Just to clarify, this is a performance issue, not a correctness one, right?

[ChadKillingsworth]

@MatrixFrog correct - performance only. However, I also share the concern.

It might be better to fix this with a peephole optimization since this is a common code pattern. It allows us to write the shorter code, but let's the compiler fix it. If ever the performance penalty is removed, we could simply undo the optimization.

This has the added benefit of fixing the pattern everywhere instead of simply not using it for transpilation.

[MatrixFrog]

Yeah, I like that approach. Out of curiosity, do we know why this is slow? Is it slow on all JS engines? Is it just because [].slice has to allocate a new array that isn't even used? Would Array.prototype.slice be faster perhaps?

[dimvar]

I'd also like to understand why the slowdown exists, before changing the transpilation.

[ChadKillingsworth]

Passing arguments out of the function scope is the culprit: https://github.com/petkaantonov/bluebird/wiki/Optimization-killers#32-leaking-arguments

While the article is V8 specific, I believe this is common among engines.

[dimvar]

Thanks for the link.

I think we should fix this at transpilation. I don't see the point in introducing slow code just to remove it later. We also want to support people who transpile but don't do optimizations. It adds some more bytes in size, but our general principle has been to make as small as possible without introducing serious performance pitfalls.

[concavelenz]

The peephole optimization for calling slice on arguments would likely still be useful but indeed is a separate issues.