- From: Boris Zbarsky <bzbarsky@MIT.EDU>
- Date: Wed, 11 Aug 2010 11:48:15 -0400
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