bruant.d at gmail.com
Tue Feb 5 04:14:26 PST 2013
Le 04/02/2013 23:11, Brendan Eich a écrit :
> Mark S. Miller wrote:
>> In any case, you may be right that this is a fatal flaw. You're
>> making a performance-based argument, and it is certainly premature
>> one way or the other to predict how these relative costs will balance
>> out. Let's wait till we have more data.
> We are not going to defer proxies from ES6 in order to implement
> notification proxies and find they cost too much. We know enough about
> allocation dwarfing other costs (direct + GC indirect), I bet. Happy
> to find out more from experiments but since we are just saying "what
> if?" I will talk back -- and make a wager on the side if you like.
> IOW, I argue that while it's ok to speculate, doing so in one
> direction (in favor of notification proxies) does not mean data must
> gathered to prove a cost is "too much" in order to not defer proxies
> from ES6. For some applications, any cost is too much, so no data is
About the performance argument, I think a performance argument can only
be made in comparison with what we have and not in absolute terms.
What's at stake with notification proxies is getting rid of invariant
checks . For some applications, the cost of invariant check is too
The right question for performance isn't "do notification proxies cost?"
but "do they cost more than direct proxies? for the main use cases? on
average? worst cast?"
Anyway, there are ideas to get rid of the per-invocation allocations on
the table, so let's explore them. If they fail, time will come to
compare posttrap allocations and invariant checks.
More information about the es-discuss