(sending from the right address this time, with apologies for the double post to the CC'd people.)
On Wed, Sep 18, 2013 at 6:56 PM, Brendan Eich <bren...@mozilla.com> wrote: > David Bruant <mailto:bruan...@gmail.com> >> September 18, 2013 12:52 PM >> >> >> 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. >> > I'm not entirely sure my feelings about an invoke trap are accurately described by the word "enthusiastic". ;) Shumway means AS3 => JS and AS3 indeed had an invoke trap (from ES4 > memories). Correct. > Actual measurements with analysis of state of implementation could be >> relevant here. >> cc'ing Till in hope he's done such measurements. >> > > Right, it's a bit rash to say performance counts for nothing. It is > usually secondary, though -- and rightly so. Optimizations come along over > time. Asymptotic complexity is a fair concern, and allocations cost -- but > if a JS JIT can prove they won't be observed then it can eliminate them. I haven't done any measurements, no. My interest in an invoke trap is mainly driven by Shumway's requirements. The fact that AS3 proxies have an invoke trap means that, as soon as any proxies are used in a vm instance at all, we have to guard all method calls in our JITted code at callsites where we can't prove that the receiver won't ever be a proxy. This affects a large percentage of Flash applications, because remoting (Flash's RPC solution) uses proxies to forward method calls on the client-side object to the server side as RPCs. Note that I don't think that "AS3 has invoke trapping and Shumway's having a hard time without JS having it, too" is a good argument, and I'm not making it. If the invoke trap is seen as superfluous or even detrimental, JS shouldn't get it. Frankly, I can't come up with very good non-Shumway-related arguments in favor of an invoke trap. It *seems* to me like being able to differentiate between method calls and property gets on the object protocol level makes sense. All I can come up with in terms of use cases is logging or forwarding of calls where your forwarding target doesn't give you the info needed to identify calls before the fact. Meaning remote procedure calls. Why you'd need to support both non-callable properties and methods on an RPC client, I don't know, however. The fact remains that, without the invoke trap, proxy users have to get the information whether a method call is about to happen from other sources, even though the runtime would be perfectly able to provide it. Putting the call-if-defined wrinkle caused (or exposed) by other spec algorithms aside for a minute, I'd argue that not providing this information makes using proxies strictly more complex, and strictly less performant. Taking that wrinkle into consideration again, I still think it might be handled by wrapping the "get function, call if get succeeded" steps used in some spec algorithms into an abstract operation. That operation could have a special case along the lines of "if the receiver is a proxy with an invoke trap, call that with the args list". That would mean that having an invoke trap causes all of these maybe-calls to be actual calls. Which seems ok to me.
_______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
