Proxy performance: JIT-compilation?

Mark S. Miller erights at
Fri Aug 4 21:22:47 UTC 2017

At 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 <ajvincent at> 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
> es-discuss at

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list