Boris Zbarsky [:bzbarsky] Reporter
	Description • 11 years ago

On the attached testcase, I consistently see ion at about 380ns per get on the proxy while BC is at 320 or so.  Oh, and interp is at 500...

	Boris Zbarsky [:bzbarsky] Reporter
	Comment 1 • 11 years ago

So looking at a profile, in the ion case almost all the time is under js::ion::GetPropertyIC::update.  This breaks down as:

* 60% under proxy_GetGeneric
* 8% under AutoFlushCache ctor
* 8% under LookupProperty
* 5% IonFrameIterator::safepoint
* 3% under TypeMonitorResult
* 3% under DetermineGetPropKind

and some long-tail stuff.  In the end, about 56% of the time is under the DOM proxy handler, and even then we end up having to do extra work to check the proto chain, even though the JIT has already done it for us in this case...

In the BC case, we end up with about 89% of our time under DoGetPropFallback, with 63% under proxy_GetGeneric and 14% under EffectlesslyLookupProperty, plus 4% TypeMonitorResult.

	Boris Zbarsky [:bzbarsky] Reporter
	Comment 2 • 11 years ago

So it seems like fundamentally we want to do the same guards as we'd do for the no-property IC on the proto here and then call into the proxy handler like we're doing for bug 870514...

	Marty Rosenberg [:mjrosenb]
	Comment 3 • 11 years ago

I'd just like to note that the AutoFlushCache ctor should be *empty* on x86.  Any time spent there is too much.

	Boris Zbarsky [:bzbarsky] Reporter
	Comment 4 • 11 years ago

It sure looks nonempty to me...  Or are you saying that this is a bug?

	Nicolas B. Pierron [:nbp]
	Comment 5 • 8 years ago

Running in a nightly build show the following numbers:

Ion: 97
BC: 104
Interp: 135 

As I am not completely sure if the techniques are working as expected for limitting compilations, so I disabled the JITs in about:config and got the following results:

Ion disabled:
Ion: 113
BC: 125
Interp: 134 

Ion & Baseline disabled:
Ion: 231
BC: 242
Interp: 254 

I think we can mark this bug as fixed.

	Boris Zbarsky [:bzbarsky] Reporter
	Comment 6 • 8 years ago

> As I am not completely sure if the techniques are working as expected for limitting compilations

They're not; e.g. we ion-compile try/catch at this point.

But yes, the numbers with ion disabled look like this is fixed now.