Le 14/11/2012 10:34, Andreas Rossberg a écrit :
On 14 November 2012 09:30, Tom Van Cutsem <[email protected]> wrote:
2012/11/13 David Bruant <[email protected]>
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
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
