Re: Speeding up mutation events

Thanks for looking at this problem.

On my part, I don't think events should be fired once with an array as param. I would prefer a filtering solution.

Other remark : As I already have said, there's a problem with CSS Selectors (that could be fixed by using XPath instead) because CSS Selectors are made to match Elements and not Nodes (so, we can't filter attributes, text nodes, comments, ...). CSS filtering may be a good solution for developers that have no knowledge about XPath and have small needs, but it's the best solution. It's at least my vision of the things.

Here's few idea about filtering event source before running a listener :

>> Maybe can this be generalised for all kind of events (then, the event is fired if the 'srcElement' of the event match the CSS/XPath selector).
>>
>> The syntax would then be :
>> [mutation_event_target].addFilteredEventListener([mutation_event_name], [filter], function(e) {...}, true/false)
>>
>> It haves the advantage that it need no specific change of the current Mutation Events implementation. It's only a change in the DOM Events.

Regards,
Fremy


From: Travis Leithead 
Sent: Thursday, June 04, 2009 2:06 AM
To: www-dom@w3.org 
Cc: iestand@microsoft.com 
Subject: 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> 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