Do we really need the [[HasOwnProperty]] internal method and hasOwn trap
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
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.
More information about the es-discuss