Slicing arguments causes huge performance drop in _.bind()

[unwitting]

Throughout, I'm referring to: http://jsperf.com/native-bind-vs-underscore

We've been noticing that _.bind (via _.bindAll) is hugely slowing down our code, and I looked into exactly what it is about _.bind that causes the slowdown.

The jsperf runs everything from native bind up to what _.bind does, with more and more of the various safety checks in between (this is assuming we never have to move on to the second line of _.bind ie that all is as expected in a sane environment). Each of these slightly (negligibly) slows down execution until moving from just referencing ctx directly instead of slice.call(arguments, 1), which halves the performance of the function in one blow.

What's the justification for the slice?

[unwitting]

This might be obsoleted if #2182 goes ahead since lodash.bind is a whopping 2 times faster than native (╯°□°）╯︵ ┻━┻ http://jsperf.com/native-bind-vs-lodash

[unwitting]

Note: a suggestion would be to offer a different call for the case in which the caller wants to provide extra arguments to bind with, since the common use case (I assume) is _.bind(fn, this), not _.bind(fn, this, other, stuff) and the safety for extra args causes such a massive perf hit.

[ZeikJT]

The slice.call being run on arguments means you're leaking arguments
https://github.com/petkaantonov/bluebird/wiki/Optimization-killers#32-leaking-arguments

The recommended fix is to do a for loop inline and create a new array based on arguments.

[jridgewell]

We can get the same speedups by dropping nativeBind.

[jdalton]

Closed by #2199.