Use for-loop, instead of slice

[jridgewell]

http://jsperf.com/trigger-with-for-loop-vs-slice

One of the optimizations I've found in the linked-list events branch is using a for-loop to grab the trigger arguments. Perf testing #trigger on that branch (with slice) against master doesn't tell the whole truth, since this slice call is the performance bottleneck. My linked-list trigger should be roughly ~8% slower than a simple array, but it's a dead heat as long as slice is in there.

[jashkenas]

Hrm. I don't know if 8% is worth it for that gross code ;)

[jamiebuilds]

@jashkenas It would definitely be worth it to me as trigger is the hottest method in all of Backbone. When I measured it a few months back it was called around 5000x on application startup in my company's app. Slicing the arguments object keeps it from optimizing that code path as much as it could.

[jridgewell]

Oh no, this is a 2000% (not a typo!) boost. I'm saying my linked-list code should be 8% slower, but it's the exact same speed because this slice is bottle-necking #trigger.

[jashkenas]

2000% boost? Now I'm confused. But holy hell.

Would this be worth pulling out as a little fastSlice helper function, and using anywhere else we're slicing an incoming arguments array?

[jashkenas]

Also, that JSPerf looks questionable. Why would three arguments be so much faster than no arguments?

Let's be careful here, before mucking things about.

[jridgewell]

Would this be worth pulling out as a little fastSlice helper function, and using anywhere else we're slicing an incoming arguments array?

That would help, but it would still de-opt because of leaking arguments. We could just use _.toArray most of the time.

Also, that JSPerf looks questionable. Why would three arguments be so much faster than no arguments?

I'm just as confused as you are. I think it's because the method isn't getting jit-d since there's not a hot loop.

[jridgewell]

Gah, one of these days I'm going to spot the errors before I post them in a PR. Here's an corrected jsperf, showing 500% increases. (I was calling For.Events.trigger, not For.trigger)

[megawac]

Ping jashkenas/underscore#1758. Mind testing with a _.slice utility that a) has the extra step arg b) doesn't (ttvm :D)

[jridgewell]

Mind testing with a _.slice utility that a) has the extra step arg b) doesn't (ttvm :D)

I'll do that shortly.

[jashkenas]

One would think that would hit your "leaking arguments" problem, but it's worth a shot.

[jridgewell]

@megawac: http://jsperf.com/trigger-with-for-loop-vs-slice/3

Using _.slice is (roughly 200%) faster than slice.call in both circumstances, but still slower than inline for-loop due to the leaky arguments. Also, it seems like it's trying to do too much: http://jsperf.com/cr-52768/6

[jameshartig]

First, thanks @jridgewell for finding this perf boost! While I agree that slice is more elegant the one-line for loop seems worth it in this case, since it's in such a hot path.

[megawac]

Would it be more appropriate to optimize _.rest to not use slice.call or any argument juggling @jridgewell?

Talk to me on gitter, ill update a jsperf tonight

[jameshartig]

But I think he's saying that it'll deopt if we pass arguments anywhere. So even passing _.rest would induce a deopt and cause it to be slower.

[megawac]

A solid rest implementation will give this a run for its money

http://jsperf.com/trigger-with-for-loop-vs-slice/5
https://github.com/megawac/backbone/compare/rest-test

[jdalton]

That jsperf was super convoluted, I cleaned it up. @jridgewell is right, passing arguments to a function will force engines to actually create the arguments object so while you may be using a faster slice-like implementation (on small to medium array-likes, reasonable for arguments) you'd still miss out on the opt of not having to create a real arg object. Engines like Chakra will materialize the arguments object in the presence of formal params too (It's something we'll fix) so that's something to keep in mind. In the revised benchmark _.rest is the slowest.

In most cases I convert the arguments object to an array in an external exposed method then pass it off as an array to internal helpers (similar to what Backbone is doing). Applying this practice to other things that are known to disqualify optimizations lets the smaller external API's tackle the disqualifications but leaves internal functions available for optimizations. In special cases I'll use a for-loop (like with a partial implementation) but that's not a common case (the gist, don't obsess all the time over it).

[megawac]

👍

[megawac]

I've got a reusable contender

http://jsperf.com/trigger-with-for-loop-vs-slice/6
https://github.com/megawac/underscore/compare/restParams
https://github.com/megawac/backbone/compare/restParams