On 7/30/14, 9:25 AM, Nicholas Nethercote wrote:
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?
First of all, for a jsperf test what really matters is what ion does
with the construct.
In SpiderMonkey, I'd think the !== version ends up with a getprop IC at
worst and a direct slot load at best, followed by whatever the !== does
(if we're lucky, just a tag test).
That's assuming we don't DCE or loop-hoist the code altogether, which in
the jsperf case we probably do (you can tell because we're doing ~1e9
loop iterations per second, which means each one is 2-3 CPU cycles, and
that _includes_ the load/increment/update of the loop counter). I've
certainly confirmed that in a local testcase that mimics what jsperf
does we either loop-hoist or DCE (hard to tell which via JIT Inspector)
the whole thing. Yay microbenchmarks?
The "in" version, for this case of a string property name, ends up doing
MIn, which does LIn, which does ends up doing a vmcall to
js::jit::OperatorIn which does a JSObject::lookupGeneric. That would be
Slow (TM). Especially compared to doing nothing.
So the short answer is that no one has really bothered to seriously
optimize "in".
http://stackoverflow.com/questions/13866442/why-is-javascripts-in-operator-consistently-slower-than-strict-member-compari
discusses this, but I'm not entirely convinced.
Yeah, that explanation is bunk.
-Boris
_______________________________________________
dev-tech-js-engine-internals mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-tech-js-engine-internals
