Currently, bound functions are not handled well by IM. We don't treat either Function.prototype.bind or calling bound functions specially, leading to performance losses. On my machine on a standard release build of inbound, --enable-optimzie --disable-debug, I see the following numbers on the attached microbenchmark: Unbound: 2ms Bound: 83ms This is just in calling them. Clearly there is much room for improvement here. I am told that There is deamnd for this certainly in JQuery, and possibly also as a result of the new arrow functions.

Interesting! This certainly affects Shumway, and I can easily imagine it affecting JSIL, too.

As far as I know we do not inlined them yet, and when we do a call I think we fallback to a native function call to call RunScript which will then enter them. So fixing the call mechanism to handle the field of JSFunctions and later looking into the same mechanism as used for the inlining lambdas.

What's a bound function in this context, other than the return value of Function.bind?

(In reply to K. Gadd (:kael) from comment #3) > What's a bound function in this context, other than the return value of > Function.bind? That's it.

OK. JSIL uses .bind for the equivalent of .NET delegate bindings (pretty common in .NET apps for event handlers, etc). The runtime library tries to avoid .bind since it's slow, but if it were fixed I'd probably use it more (especially since the workaround typically means custom .apply and .call methods, which V8 hates)

It seems this has been improved a lot. Unbound: 6ms Bound: 13ms WFM?

(In reply to Guilherme Lima from comment #6) > It seems this has been improved a lot. > Unbound: 6ms > Bound: 13ms > > WFM? Not quite: while call performance is pretty good, bound functions still have huge stack frames, meaning they impose pretty tight limits on recursion depth (see bug 1093158), and performance of the binding operation itself and of constructing bound functions is still not that great. I hope to address all of this in bug 1000780. Sadly, I don't have much time to work on it, though :(

After bug 1000780: Unbound: 4ms Bound: 7ms

(In reply to Guilherme Lima from comment #8) > After bug 1000780: > Unbound: 4ms > Bound: 7ms I get 3 ms and 5 ms before bug 1240127 (MTableSwitch optimization) landed. With that patch, I get 3 ms for both bound and unbound. There are still cases that are slow, but the most common ones (<= ~5 arguments or so) are optimized really well now.

Just to confirm, on today's Nightly (with bug 1240127 fixed) I see 4ms for both cases.