The global object in browsers

Maciej Stachowiak mjs at apple.com
Thu Feb 19 11:34:03 PST 2009


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 <ian at hixie.ch> 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. 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.

Regards,
Maciej


More information about the Es-discuss mailing list