896710 - IonMonkey: Consider bound function performance

Status: RESOLVED FIXED

(Core :: JavaScript Engine, defect)

Description

[Eric Faust [:efaust]]

Attachment: Bound function microbench

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.

Comment 1

[Till Schneidereit [:till]]

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

Comment 2

[Nicolas B. Pierron [:nbp]]

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.

Comment 3

[Katelyn Gadd (:kael)]

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

Comment 4

[Eric Faust [:efaust]]

(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.

Comment 5

[Katelyn Gadd (:kael)]

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)

Comment 6

[Guilherme Lima]

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

WFM?

Comment 7

[Till Schneidereit [:till]]

(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 :(

Comment 8

[Guilherme Lima]

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

Comment 9

[Jan de Mooij [:jandem]]

(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.

Comment 10

[Guilherme Lima]

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