[[Invoke]] and implicit method calls
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
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
2. Till's use case.
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