Maciej Stachowiak wrote: > On Feb 19, 2009, at 1:39 AM, David-Sarah Hopwood wrote: >> Ian Hickson wrote: >>> On Tue, 17 Feb 2009, Mark Miller wrote: >>>> On Tue, Feb 17, 2009 at 5:03 PM, Ian Hickson <[email protected]> wrote: >>>>> Indeed, I noted this earlier. The behavior HTML5 codifies is the >>>>> behavior that the majority of browser vendors have asked me to codify. >>>> Majority, huh? Which vendors? How does the behavior they ask for >>>> correlate with what their browsers do? >>> >>> Opera, Apple, and Mozilla. The HTML5 spec originally specced what IE >>> does, namely throw an exception when running code whose global object >>> doesn't >>> match the current Window object, but Opera, Apple, and Mozilla rejected >>> this on the grounds that it could not be implemented in a >>> high-performance manner. >> >> That is clearly false. It would be a single pointer comparison when >> entering a new context. >> >> I make no comment here on whether this behaviour would be a good idea on >> other criteria, just that rejecting it on performance grounds is absurd. > > In modern JITing implementations, adding (at least) two memory reads and > a conditional branch to every function call would be a significant > performance hit.
It is not every function call; only function calls that are not known to be same-context (in a particular copy of the generated code). The majority (by call frequency) of function calls can be inferred to be same-context by analyses that a high-performance implementation should be doing already. Furthermore, the context check can be hoisted to the first point in a function body where the target function is known (so calls to the same function in a loop will require only one check). There are most sophisticated optimizations that could be done, but they're probably not needed. > In JavaScriptCore for instance, the hot path at the > machine code level is optimized down to essentially just one memory > read, one conditional branch, and a jump to the callee's code (also some > memory writes but those don't stall the pipeline so they don't matter as > much). The next hottest path has three branches and a few extra memory > reads. Adding an extra branch (and associated memory reads) to that > would be a big hit. We know because we have measured the benefit of > reducing the number of branches. It makes a huge difference in > call-heavy code. > > In general, I would advise against making performance claims in absolute > terms (like "clearly false") without testing or studying the relevant > implementation internals. I see no point in equivocating on points that I am quite sure about, having studied similar issues in implementations of other languages. -- David-Sarah Hopwood _______________________________________________ Es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
