W3C home > Mailing lists > Public > www-dom@w3.org > April to June 2009

Re: Why 'mutation events' are not so slow, relatively

From: Boris Zbarsky <bzbarsky@MIT.EDU>
Date: Sun, 07 Jun 2009 08:32:16 -0400
Message-ID: <4A2BB350.5060707@mit.edu>
To: Fran├žois REMY <fremycompany_pub@yahoo.fr>
CC: DOM WG <www-dom@w3.org>
Fran├žois REMY wrote:
>> You don't think a 3-10x slowdown (from your own data; my data agrees 
>> on the general range) is problematic?
> 
> I don't think they are problematic because the data shows that it can be 
> translated
> into a x2 / x2.5 range. Which is not a problem if we consider that the 
> time used
> by adding an element to the DOM is really small, relatively to the time 
> the UA
> need to render it.

Note that your test was not apples-to-apples in this regard; last I 
checked insertion does more of the renderin step in Firefox than in 
other browsers.

But in any case, I think your "time used to add is really small compared 
to time needed to lay out" is not necessarily true.  In your testcase, 
for example, it's a lot bigger (as you can check by forcing layout while 
still timing the testcase).

But even if we assume a 2-2.5x range, that's still quite noticeable. 
Worth several person-years of work to a browser maker to get a speedup 
like that.

> As you may have noticed, we speek about change of speed less an a 10th of
> second.

For a single operation.  The problems come when people repeatedly mutate 
the DOM.

> Even with a whole page's loading, we can't have a slowdown of more
> than a second, which is acceptable (because no site would rely on a 
> mutation
> event before the page load).

At least some browsers don't fire mutation events before pageload (or 
rather for the changes their parser makes).  But the worry here is not 
pageload.  The worry is DOM mutation of an existing page (think gmail or 
zimbra or some such).

Also note that "a second" is a huge time for loading a webpage, in terms 
of CPU time.  If you load them from local disk, most webpages out there 
load in under 0.5 seconds in modern browsers...

> Another thing we need to look at : What would be the time lost by the 
> browser if we did the 'style' change (in my first example) by using a 
> setInterval and a filtering of elements to find 'newly' inserted elements ? This is currently the 
> best way to do the same thing without using mutation events.

I don't think anyone's proposing having no mutation notifications at 
all, now are they?

Also, how common is this use case of wanting to modify style for various 
nodes you're not inserting yourself?

-Boris
Received on Sunday, 7 June 2009 12:32:57 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 22 June 2012 06:14:00 GMT