Sorry to bump in, but I am interested if those are good beginner bugs, would
that be OK?
Thanks,
Ting
- Original Message -
> From: "Kannan Vijayan"
> To: dev-tech-js-engine-internals@lists.mozilla.org
> Sent: Wednesday, July 30, 2014 9:44:12 PM
> Subject: Re: [JS-internals] 'in' operator
On Wed, Jul 30, 2014 at 3:59 PM, Boris Zbarsky wrote:
> 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).
>
FWIW, it's a direct slot load and the !== will be folde
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 cons
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 w
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
discusse
5 matches
Mail list logo