The simple reason is that we don't optimize this case in Ion yet.
Looking at IonBuilder's handling of JSOP_IN, it optimizes the case where
the property being checked for is a dense element and the object is
well-known, but it doesn't optimize property checks.
The "full treatment" of this op would include the following:
1. Optimize property checks using Type-Inference. This will only work
for definite properties.
2. Optimize property checks using Baseline IC stubs, inlining shape
guards into the main jitcode body.
3. Optimize property checks using Ion ICs.
These are, in fact, really good beginner bugs. Most of the logic here
will be equivalent to the GetProp implementations, except instead of
returning the value from the property slot, it will return true/false..
so there's a good existing reference for how to implement this.
Kannan
On 2014-07-30, 9:25 AM, Nicholas Nethercote wrote:
Hi,
The following jsperf microbenchmark suggests that |p in o| is much
slower than |o.p !== undefined|: http://jsperf.com/in-vs-not-undefined
Can someone explain why?
http://stackoverflow.com/questions/13866442/why-is-javascripts-in-operator-consistently-slower-than-strict-member-compari
discusses this, but I'm not entirely convinced. Maybe the ToString()
required for 'in' explains it?
Thanks.
Nick
_______________________________________________
dev-tech-js-engine-internals mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-tech-js-engine-internals
_______________________________________________
dev-tech-js-engine-internals mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-tech-js-engine-internals
