A case for removing the seal/freeze/isSealed/isFrozen traps

Brendan Eich brendan at mozilla.com
Thu Feb 14 13:55:48 PST 2013

Andreas Rossberg wrote:
> On 14 February 2013 19:16, David Bruant<bruant.d at gmail.com>  wrote:
>> Le 14/02/2013 18:11, Andreas Rossberg a écrit :
>>> You're being vastly over-optimistic about the performance and the
>>> amount of optimisation that can realistically be expected for proxies.
>>> Proxies are inherently unstructured, higher-order, and effectful,
>>> which defeats most sufficiently simple static analyses. A compiler has
>>> to work much, much harder to get useful results. Don't expect anything
>>> anytime soon.
>>      var handler = {set: function(){throw new TypeError}}
>>      var p = new Proxy({a: 32}, handler);
>>      p.a;
>> It's possible *at runtime* to notice that the handler of p doesn't have a
>> get trap, optimize p.[[Get]] as target.[[Get]] and guard this optimization
>> on handler modifications. Obviously, do that only if the code is hot.
>> I feel it's not that much work than what JS engines do currently and the
>> useful result is effectively getting rid of the forwarding overhead.
>> Is this vastly over-optimistic?
> Yes. Proxies hook into many different basic operations, and there are
> many special cases you could potentially optimise for each of them,
> many of which don't come for free. I very much doubt that any vendor
> currently has serious plans to go down that rathole instead of
> spending their energy elsewhere. Certainly not before it is clear how
> (and how much) proxies will actually be used in practice.

You're right in general, and we have not optimized, e.g. inlining 
scripted trap calls.

We did do something special for our new DOM bindings I wanted to pass 
along, in case anyone is interested:


Thanks to bz for the link. This is yet another inline cache 
specialization for expandos on nodelists.


More information about the es-discuss mailing list