W3C home > Mailing lists > Public > whatwg@whatwg.org > August 2010

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

From: Boris Zbarsky <bzbarsky@MIT.EDU>
Date: Wed, 11 Aug 2010 11:48:15 -0400
Message-ID: <4C62C63F.6090801@mit.edu>
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
Received on Wednesday, 11 August 2010 08:48:15 UTC

This archive was generated by hypermail 2.3.1 : Monday, 13 April 2015 23:08:59 UTC