- From: Boris Zbarsky <bzbarsky@MIT.EDU>
- Date: Thu, 25 Jun 2009 23:59:29 -0400
- To: Sean Hogan <shogun70@westnet.com.au>
- CC: DOM public list <www-dom@w3.org>
Sean Hogan wrote:
>> Just as a data point, Gecko trunk had a bug earlier today where we
>> accidentally introduce a performance regression on removing table
>> rows. The bug was easily caught because the regression made removing
>> a table row O(N) in number of rows and it immediately turned out that
>> all sorts of pages out there sort multi-thousand-row tables by
>> reordering the row nodes in the DOM.
> Can you provide some URLs?
Here's an example:
http://crash-stats.mozilla.com/report/list?product=Firefox&version=Firefox%3A3.0&version=Firefox%3A3.0.1&version=Firefox%3A3.0.10&version=Firefox%3A3.0.10pre&version=Firefox%3A3.0.11&version=Firefox%3A3.0.11pre&version=Firefox%3A3.0.12pre&version=Firefox%3A3.0.1pre&version=Firefox%3A3.0.2&version=Firefox%3A3.0.2pre&version=Firefox%3A3.0.3&version=Firefox%3A3.0.4&version=Firefox%3A3.0.4pre&version=Firefox%3A3.0.5&version=Firefox%3A3.0.5pre&version=Firefox%3A3.0.6&version=Firefox%3A3.0.6pre&version=Firefox%3A3.0.7&version=Firefox%3A3.0.7pre&version=Firefox%3A3.0.8&version=Firefox%3A3.0.8pre&version=Firefox%3A3.0.9&version=Firefox%3A3.0.9pre&version=Firefox%3A3.0b1&version=Firefox%3A3.0b2&version=Firefox%3A3.0b3&version=Firefox%3A3.0b4&version=Firefox%3A3.0b5&version=Firefox%3A3.0b5pre&version=Firefox%3A3.0pre&version=Firefox%3A3.1a1&version=Firefox%3A3.1a1pre&version=Firefox%3A3.1a2&version=Firefox%3A3.1a2pre&version=Firefox%3A3.1b1&version=Firefox%3A3.1b1pre&version=Firefox%3A
3.1b2&version=Firefox%3A3.1b2pre&version=Firefox%3A3.1b3&version=Firefox%3A3.1b3pre&version=Firefox%3A3.1b4pre&version=Firefox%3A3.2a1pre&version=Firefox%3A3.5&version=Firefox%3A3.5b4&version=Firefox%3A3.5b4pre&version=Firefox%3A3.5b5pre&version=Firefox%3A3.5b99&version=Firefox%3A3.5pre&version=Firefox%3A3.6a1pre&platform=mac&query_search=signature&query_type=contains&query=nsObjCExceptionLogAbort&date=&range_value=4&range_unit=weeks&do_query=1&signature=nsObjCExceptionLogAbort%28NSException*%29%20|%20nsAppShell%3A%3AProcessGeckoEvents%28void*%29
>> Which means that they're doing thousands to tens of thousands of DOM
>> mutations. And the time required needs to stay small (under 200ms,
>> ideally, since that's about whether the user starts perceiving the
>> operation as laggy).
>>
> But in this case they wouldn't be using Mutation Events.
Wouldn't they? Here's the entirety of the code on that page that does
the table sorting:
$(document).ready(function() {
$('#reportsList').tablesorter({sortList:[[9,1]]});
});
Why wouldn't some other part of the page script, or of jquery, or of
some random ad on the page if this were a page with ads happen to use
mutation events?
> Sure. Every feature has its costs, and sometimes those costs mean you
> don't use it.
> I think the page author should make that decision for Mutation Events.
A lot of the more interesting pages (heck, the one cited above!)
effectively have more than one author, so it's not that hard to get into
situations where one of them decides to use mutation events and another
has code that needs to run fast.
-Boris
Received on Friday, 26 June 2009 04:00:17 UTC