[[Invoke]] and implicit method calls

Jason Orendorff jason.orendorff at gmail.com
Wed Sep 18 14:38:27 PDT 2013

On Wed, Sep 18, 2013 at 11:52 AM, David Bruant <bruant.d at gmail.com> wrote:
> Le 17/09/2013 15:36, Jason Orendorff a écrit :
>> The performance argument is a non-starter
> Why? (damned! how do I find myself defending invoke while I'm relatively
> against it...)
> Till Schneidereit's enthusiasm about it and the promised boost for Shumway
> suggests that the performance difference is significant to not be a
> non-starter.

OK, I'll unpack this. There are two different performance arguments.

1. "Method calls on proxies will be faster with the .invoke hook."

   I think implementations can optimize this transparently, if it
matters. Also, I could be wrong, but I think implementers generally
don't want TC39 to help them optimize things by adding extra features.

   Also, I think this doesn't matter. It's hard to prove a negative,
but here's a data point: CPython has been around 22 years now and to
this day allocates a new bound-method object for every single method
call. Not just proxies. All objects. All methods! Granted, CPython
doesn't aspire to JS-like performance—but they do care about speed,
and this would be low-hanging fruit for them if it mattered. Unlike
the proposal we're talking about, it could be done transparently and
would affect **all existing Python code**. Why haven't they done it? A
little inline cache. It’d be easy.

   It just doesn't matter. The most performance-critical stuff won't
be able to afford going through a proxy, full stop. Everything else
won't care if there's one trap or two. (The occasionally-alleged use
cases involving Proxy handlers doing high-latency remote procedure
calls seem like a bit of a stretch, given the async world that JS
actually inhabits.)

2. Till's use case.

   Till is translating ActionScript to JavaScript. ActionScript has
something like invoke traps:

   From Till's perspective, any AS method call could be a proxy method
call. It becomes much easier to translate them to fast JS code if we
just add .invoke traps to JS as well.

   As much as I admire the Shumway project, this isn't a good reason
to add a language feature.

I think both performance arguments are non-starters, not because I
dismiss such arguments out of hand (I don't) but because I looked and
they just don't go.


More information about the es-discuss mailing list