[whatwg] HTML5 (including next generation additions still in development) - Mozilla Firefox (Not Responding)

Boris Zbarsky bzbarsky at MIT.EDU
Wed Aug 11 08:48:15 PDT 2010


On 8/11/10 10:31 AM, Garrett Smith wrote:
> It would have been more helpful to explain, if you can, the cause of
> the slowness in Firefox..

Sure thing.  https://bugzilla.mozilla.org/show_bug.cgi?id=481131#c12 
(the paragraph starting "The time") and 
https://bugzilla.mozilla.org/show_bug.cgi?id=481131#c17

Note that I was wrong in my previous mail; it's status.js that causes 
the mutations that trigger the Firefox bug, not to.js

>>> Looping through the dom on page load is something that is best avoided.
>>
>> That's not an issue here.
>>
>
> No. Actually it *is* an issue here; that issue is just massively
> dwarfed by the other issue behind door #2.

What makes you say that "looping through the dom" is a performance issue?

In case you care, an actual loop through the DOM on the HTML5 
single-page spec, like so (making sure to touch all the nodes, etc):

javascript:var start = new Date(); function f(n) { for (var k = 
n.firstChild; k; k = n.nextSibling) f(k); } f(document); alert(new 
Date() - start)

alerts numbers under 50ms for me in all the browsers I've tried that can 
load the spec to start with.

>>> Most (if not all) of this stuff seems best suite for server-side
>>> logic.
>>
>> That's possible; I'm assuming Ian had a reason for setting it up the way
>> he did.
>
> Possible where? On w3c server or whatwg server?

It's possible that the output the scripts generate is more suited to 
being generated server-side.  I made no comment on the feasibility of 
doing so, since I have no idea what the server setup looks like.

-Boris



More information about the whatwg mailing list