Jason Orendorff <mailto:[email protected]>
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.
/be
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
