Do we really need the [[HasOwnProperty]] internal method and hasOwn trap

David Bruant bruant.d at gmail.com
Mon Nov 19 03:33:57 PST 2012


Le 14/11/2012 10:34, Andreas Rossberg a écrit :
> On 14 November 2012 09:30, Tom Van Cutsem <tomvc.be at gmail.com> wrote:
>> 2012/11/13 David Bruant <bruant.d at gmail.com>
>>> For the particular case you've written, when going for hasOwnProperty.call
>>> or the in operator, the JS engine knows it needs to output a boolean, so it
>>> can "rewrite" (or contextually compile) your trap last line as
>>> "e===undefined" (since "undefined" is falsy and objects created by object
>>> literals are truthy). In that particular case, the allocation isn't
>>> necessary provided some simple static analysis.
>>> Maybe type inference can be of some help to prevent this allocation in
>>> more dynamic/complicated cases too. I would really love to have implementors
>>> POV here.
>> I'm very skeptical of this.
>>
>> If I may summarize, you're arguing that we can get away with spurious
>> allocations in handler traps because JS implementations can in theory
>> optimize (e.g. partially evaluate trap method bodies). I think that's
>> wishful thinking. Not that implementors can't do this, I just think the
>> cost/benefit ratio is way too high.
> I agree, this is a particularly daring instance of the "sufficiently
> smart compiler" argument.
I've been thinking about this message for a few days and I think I've 
made up my mind about it.
In a lot of our discussions, we mention performance. As far as 
implementors are concerned, the incentive is removing the biggest 
bottlenecks as they are noticed. That's probably why a lot of 
optimizations related to strict mode haven't been leveraged.

I think that what this means for us (people who are discussing evolution 
of the language) is that we can't know which implementations will be 
done. We can think the evolution of the language in a way that prevent 
design-induced performance issues.

The cost/benefit ratio or "sufficiently smart compiler" is not really up 
to people on this list, and especially not today. It will have to be 
decided by implementors in due time if they ever notice something to be 
a bottleneck.
Maybe that without the static analysis I mentioned the extra allocation 
that Tom mentioned would never be a considered as a bottleneck requiring 
to optimize this case and that could be fine.

So my position is let's not bake performance bottlenecks in the language 
(which we tend to do naturally anyway) and for things that can be 
optimized, let's say that the implementations will pay the cost of the 
static/runtime analysis if it's really felt by them like a worthwhile idea.

David


More information about the es-discuss mailing list