[[Invoke]] and implicit method calls

Brendan Eich brendan at mozilla.com
Wed Sep 18 19:11:28 PDT 2013

> Jason Orendorff <mailto:jason.orendorff at gmail.com>
> September 18, 2013 5:38 PM
> 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.

CPython refcounts, which means eager free. Bet if they used naive GC 
they'd have done something.

> 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.)

Boris is working on Proxy-based form objects. You may be right that they 
are not on perf critical paths.

> 2. Till's use case.
> Till is translating ActionScript to JavaScript. ActionScript has
> something like invoke traps:
> http://help.adobe.com/en_US/FlashPlatform/reference/actionscript/3/flash/utils/Proxy.html
> 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.

Agreed, it's just another bean on the pile. There need not be one 
reason, or only one or a few big reasons.

> 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.

Your CPython argument is suspect, but the real data we seek is a 
JS-specific perf bake-off, more than Shumway but at least that: some 
significant macro-benchmark suite that exercises method calls and 
methods as funargs, and that is not synthetic or based on old/rare real 
world code.


More information about the es-discuss mailing list