At https://github.com/tvcutsem/es-lab/issues/21 Tom and I have an idea (that we should turn into a proposal) for a subtle change to proxy semantics that * should break essentially no current code, * repair the cycle detection transparency violation bug, * enable many proxies to be *much* faster.
On Fri, Aug 4, 2017 at 2:15 PM, Alex Vincent <[email protected]> wrote: > Recently, a fellow engineer observed that ECMAScript proxies are "around > 700x slower" in retrieving a property than a simple getter function with a > closure. He thought this meant "the JIT compiler can't optimize the code". > > I'm not so sure, so I thought I'd ask the experts here. > > Proxies are one of the frontiers of JavaScript, largely unexplored. The > ECMAScript specification makes no mention whatsoever of just-in-time > compilation (rightly so, I would think). But this means that proxy code > execution might be one of those areas where we do not currently enjoy the > benefits of JIT... and we could. > > So, I have a direct question for JavaScript engine developers: other than > having to look up and execute a proxy handler's traps, are there specific > reasons why proxy performance might be significantly slower than a simple > function execution? > > I can imagine a three-fold performance test: (1) direct inspection of an > object, (2) inspection of Proxy({}, Reflect), and (3) inspection of > Proxy({}, handler) where > > allTraps.forEach(function(t) { > handler[t] = function() { > return Reflect[t].apply(Reflect, arguments); > } > }); > > -- > "The first step in confirming there is a bug in someone else's work is > confirming there are no bugs in your own." > -- Alexander J. Vincent, June 30, 2001 > > _______________________________________________ > es-discuss mailing list > [email protected] > https://mail.mozilla.org/listinfo/es-discuss > > -- Cheers, --MarkM
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
