Speeding up mutation events

We've heard a lot of feedback that mutation events are slow.

I'd like to propose we think along two lines for "fixing" them (note, we probably can't just "replace" the old events for legacy compat, but we can recommend alternate solutions):


1.       What are aspects of the mutation events that make them slow, and is there an evolutionary approach to speeding them up?

2.       What are alternate ideas that solve the same user scenarios as mutation events, but have the possibility of being much more performant?

Just brainstorming within IE, for #1 we were thinking along the lines of "batching" such that mutation events that might fire over-and-over after a given event like innerHTML could be batched by firing the event just once, but passing in the list of affected objects as a parameter-something like that.

For #2, I pass along the "watchSelector" mail thread from the jsninjas group. To me, this appears to be a "mutation event" notification of sorts, but with the added benefit of having a built-in filtering language. CSS selectors are used in this case, but I could imagine other filtering languages as well (e.g., xpath). The thought was to put this into Selectors API v2, but I thought I'd pass it along here as well.

---


From: jsninjas@googlegroups.com [mailto:jsninjas@googlegroups.com] On Behalf Of John Resig

Sent: Tuesday, March 03, 2009 1:53 PM

To: jsninjas@googlegroups.com

Subject: Re: We don't need onload any more, right?



Yes, DOM mutation events already exist (in Firefox and Opera - fairly reliably - and dicey in Safari). They have a huge problem, though:

They absolutely cripple DOM performance on any page which they're enabled.



Firefox, for example, when it realizes that a mutation event has been turned on, instantly goes into an incredibly-slow code path where it has to fire events at every single DOM modification. This means that doing something like .innerHTML = "foo" where it wipes out 1000 elements would fire, at least 1000 + 1 events (1000 removal events, 1 addition event).



The heart of the idea is good (wanting to know when things update) but the DOM spec kills its real-world applicability.



About the events:

http://www.w3.org/TR/DOM-Level-2-Events/events.html#Events-eventgroupings-mutationevents



That being said, the above proposed "know when a query updates" would be sweet - perhaps we can push the W3C to get this in for Selectors API 2.



--John





On Tue, Mar 3, 2009 at 4:48 PM, Stuart Langridge <sil@kryogenix.org<mailto:sil@kryogenix.org>> wrote:

[...]

>> If we had Element.prototype.matchesSelector we could achieve

>> something similar with mutation events. However, I think the usecase

>> is to get callbacks when an element is starts or stops matching a CSS selector.

>> Something like:

>>

>> watchSelector('.abc[disabled]', function(added, element) {

>>  if (added) init(element);

>>  else cleanup(element);

>> });

[...]

> sil