Re: Speeding up mutation events

If we are replacing the current mutation event spec with something
new, which I really think we should, I would suggest replacing it with
something that doesn't use events. DOM Events simply have a lot of
overhead due to the event propagation. Mutation events also currently
have the problem that they are very unreliable, in the sense that by
the time your event handler gets called about an attribute value being
set, some other handler might already have set it to some other value.
I don't see any way of fixing that while still using DOM Events.

I'll try to come up with an alternative proposal shortly.

/ Jonas

On Wed, Jun 3, 2009 at 5:06 PM, Travis Leithead
<Travis.Leithead@microsoft.com> wrote:
> 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
>
>

Received on Thursday, 4 June 2009 07:00:53 UTC