On Jun 21, 2011, at 11:33 AM, Oliver Hunt wrote: > I'm answering some of the performance questions in this, but i don't know > what the intended semantics of 'dynamic super' would be so I can't give > specific details of most of the use cases. If it's essentially sugar for > super.foo => Object.getPrototypeOf(this).foo (with appropriate munging for > calls, etc) then the cost is at point of use only, but if it's anything more > fun (there are references to additional implicit parameters below which would > be fairly bad for performance of calls)
That's the point: super must mean something other than Object.getPrototypeOf(this). Otherwise with the prototypal pattern you will infinitely recurse calling the same prototype-homed foo from foo via super.foo(). If super was shorthand only for Object.getPrototypeOf(this), then there's hardly any point in making super short for that expression. Axel's notion of a |here| object helps, in that Object.getPrototypeOf(here) is more what you want from 'super' -- but not necessarily when the method has been borrowed by another object used as |here|. Note the "necessarily" -- you may know how to rebind 'super', but you may not. Allen's Object.defineMethod requires an affirmative defense before you can rebind super. It's a safety step, since 'super' is an internal function property and *not* a free parameter. BTW I do not agree we can or should try to reserve 'here' or expose the method's "home object" -- that breaks abstractions built using prototypes. 'super' does not, because it always goes to the [[Prototype]] of the object in which the method was defined. /be > > On Jun 21, 2011, at 11:04 AM, Sean Eagan wrote: >> I disagree that a dynamic super would lead to a '50% increase in > >> argument passing overhead, on average'. First, there is the implicit >> 'arguments' argument, which is an object that actually needs to be >> created per call site, not just a binding, and thus is presumably much >> more expensive. > Nope, creating an arguments object is on average free, as most uses can be > lowered. > >> Second, 'argument passing overhead' involves sunk >> costs that are not dependent on the number of argument bindings that >> need to be created. > Every additional argument has a performance cost > >> Third, implicit arguments, as 'super' would be, >> should be less costly than explicit arguments since the argument value >> does not need to be resolved. > > I haven't really been following this but why does super need to be passed as > an additional parameter? > >> >> A better estimate of the overhead of dynamic super would probably be >> the overhead of an implicit 'this' binding, i.e. the cost of creating >> a 'this' binding for a function activation that not involving an >> explicit 'this' via Function.prototype.call or >> Function.prototype.apply, or Function.prototype.bind. Does anyone >> have any estimates of this cost, either absolute or relative to some >> other cost? > > That depends on the exact use case. JSC doesn't determine what |this| is at > the callsite (In general strict mode makes that impossible), so it becomes a > question of whether you use it or not. > >> I was unaware that dynamic super had been discussed, proposed, or >> attempted previously for ES, or that it was ever included to have >> 'pervasive overhead'. Do you any references for this? > > No idea -- it would depend on what the actual semantics of super were >
_______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
