Mutation events

[Olli Pettay]

Hi all,

I tested mutation events a bit.

                             | Gecko trunk | WebKit trunk | Opera 10a
DOMAttrModified             |      X      |      -       |     X
DOMCharacterDataModified    |      X      |      X       |     X
DOMNodeInserted             |      X      |      X       |     X
DOMNodeInsertedIntoDocument |      -      |      X       |     X
DOMNodeRemoved              |      X      |      X       |     X
DOMNodeRemovedFromDocument  |      -      |      X       |     X
DOMSubtreeModified          |      X      |      X       |     -


Whenever mutation listeners are used, the relevant DOM operations slow
down a lot in all browser engines. The slow down is up to 10-20x.




I also discussed with some ARIA folks and asked whether it would make
sense to have ARIAAttrModified event (it should be defined in some
ARIA spec). Currently WAI-ARIA best practices[1] recommends using
DOMAttrModified.
IMHO it is a bit strange to utilize mutation events when external AT
software wants to notify a web page that it changed something.
It works, sure, but some ARIA specific API or event might be better.



-Olli

[1] http://www.w3.org/WAI/PF/aria-practices/#aria-write

[Stewart Brodie]

Olli Pettay <Olli.Pettay@...> wrote:

> Hi all,
>
> I tested mutation events a bit.
>
>                              | Gecko trunk | WebKit trunk | Opera 10a
> DOMAttrModified             |      X      |      -       |     X
> DOMCharacterDataModified    |      X      |      X       |     X
> DOMNodeInserted             |      X      |      X       |     X
> DOMNodeInsertedIntoDocument |      -      |      X       |     X
> DOMNodeRemoved              |      X      |      X       |     X
> DOMNodeRemovedFromDocument  |      -      |      X       |     X
> DOMSubtreeModified          |      X      |      X       |     -
>
>
> Whenever mutation listeners are used, the relevant DOM operations slow
> down a lot in all browser engines. The slow down is up to 10-20x.

My implementation also does all of the events except SubtreeModified.  The
slowdown factor will depend on what mutations you are actually doing.  I
don't expect our implementation to slow down at all unless you are actually
listening for the events.


--
Stewart Brodie
Software Engineer
ANT Software Limited

[Olli Pettay]

On 3/11/09 4:26 PM, Stewart Brodie wrote:
> My implementation also does all of the events except SubtreeModified.

> The
>  slowdown factor will depend on what mutations you are actually doing.
Sure. I was testing with a deep DOM tree and using a listener which
doesn't actually to anything. The point was just to show that the
slow down can be significant.


>  I
> don't expect our implementation to slow down at all unless you are actually
> listening for the events.
Right, this is what happens in browsers too. Mutation events aren't even
dispatched unless there are listeners.


-Olli

[Boris Zbarsky]

Stewart Brodie wrote:
> My implementation also does all of the events except SubtreeModified.  The
> slowdown factor will depend on what mutations you are actually doing.  I
> don't expect our implementation to slow down at all unless you are actually
> listening for the events.

Right.  Olli is talking about the slowdown when an operation there is a
listener for happens.  So if you're listening for DOMAttrModified, any
attribute change (including foo.style.* changes).

-Boris

[Cameron McCormack-4]

Boris Zbarsky:
> Right.  Olli is talking about the slowdown when an operation there is a  
> listener for happens.  So if you're listening for DOMAttrModified, any  
> attribute change (including foo.style.* changes).

Could a solution to this be to allow listeners to be registered
(somehow; the DOM Events model doesn’t support this at the moment) for
particular attributes?

--
Cameron McCormack ≝ http://mcc.id.au/

[Sergey Ilinsky]

Boris Zbarsky wrote:
> Right.  Olli is talking about the slowdown when an operation there is
> a listener for happens.  So if you're listening for DOMAttrModified,
> any attribute change (including foo.style.* changes).
>
> -Boris
The sample scenario you provided might not be correct. I would argue
that changes made to foo.style object should necessarily lead to the
foo@style attribute value change, similarly to input.value property not
leading to the change of input@value attribute etc. The attribute unless
modified by the means of DOM methods (such as removeAttributeNode,
setAttributeNS etc. that will actually lead to a dispatch of
DOMAttrModified) should preserve its value observed from markup.

Sergey Ilinsky/

[Jonas Sicking-2]

Cameron McCormack wrote:
> Boris Zbarsky:
>> Right.  Olli is talking about the slowdown when an operation there is a  
>> listener for happens.  So if you're listening for DOMAttrModified, any  
>> attribute change (including foo.style.* changes).
>
> Could a solution to this be to allow listeners to be registered
> (somehow; the DOM Events model doesn’t support this at the moment) for
> particular attributes?

That would help with modifications to other attributes, sure, but it
wouldn't help with modifications to the attribute for which there are
listeners.

It also wouldn't help with any other DOM mutations (e.g. inserting and
removing children).

/ Jonas

[Sean Hogan]

Olli Pettay wrote:
> Hi all,
>
> I tested mutation events a bit.
>
>
> Whenever mutation listeners are used, the relevant DOM operations slow
> down a lot in all browser engines. The slow down is up to 10-20x.
>

In the browser at least, almost all the node-inserted/removed operations
would require a rendering update, and many attr-modified operations
could too. I expect most mutation handlers would also kick off a change
in rendering or even access to a network resource. Is the overall
browser response time (including screen / network updates) degraded?

[Boris Zbarsky]

Cameron McCormack wrote:
> Could a solution to this be to allow listeners to be registered
> (somehow; the DOM Events model doesn’t support this at the moment) for
> particular attributes?

That might help performance, yes, though only at a certain memory cost
on the UA end.

I think Olli's suggestion that aria-specific events are the way to go
here is the one that requires the fewest changes in browser
implemenations (more or less none) and specifications (also none for the
existing specifications).  It does require that someone dispatch those
events, of course.

-Boris

[Boris Zbarsky]

Sergey Ilinsky wrote:
> The sample scenario you provided might not be correct. I would argue
> that changes made to foo.style object should necessarily lead to the
> foo@style attribute value change, similarly to input.value property not
> leading to the change of input@value attribute etc.

Except that the DOM spec for input.value specifically says that changing
it does not change the "value" attribute, while the DOM spec for
.style.* explicitly says that the property represents nothing other than
the style attribute.

> The attribute unless modified by the means of DOM methods (such as removeAttributeNode,
> setAttributeNS etc. that will actually lead to a dispatch of
> DOMAttrModified) should preserve its value observed from markup.

That's not the observed behavior of UAs last I checked, not correct per
the DOM 2 Style spec, and not compatible with the web last I checked.

-Boris

[Sergey Ilinsky]

--- On Wed, 11/3/09, Boris Zbarsky <bzbarsky@...> wrote:

> Except that the DOM spec for input.value specifically says
> that changing it does not change the "value"
> attribute, while the DOM spec for .style.* explicitly says
> that the property represents nothing other than the style
> attribute.

Right, the value attribute property was likely an exception because of the form reset funcionality.

> That's not the observed behavior of UAs last I checked,
> not correct per the DOM 2 Style spec, and not compatible
> with the web last I checked.

Again correct, couple of tests I've done prove your words.


Sergey/

[mikewse]

[resurrecting an old thread]

Hi Olli,
Would it be possible to post a bit more detailed performance data? It would be interesting to see what events have the least slow-down and what that amounts to :-)
Best regards
Mike Wilson

Olli Pettay wrote:

Hi all,

I tested mutation events a bit.

                             | Gecko trunk | WebKit trunk | Opera 10a
DOMAttrModified             |      X      |      -       |     X
DOMCharacterDataModified    |      X      |      X       |     X
DOMNodeInserted             |      X      |      X       |     X
DOMNodeInsertedIntoDocument |      -      |      X       |     X
DOMNodeRemoved              |      X      |      X       |     X
DOMNodeRemovedFromDocument  |      -      |      X       |     X
DOMSubtreeModified          |      X      |      X       |     -

Whenever mutation listeners are used, the relevant DOM operations slow
down a lot in all browser engines. The slow down is up to 10-20x.

[mikewse]

Jonas Sicking wrote:

> Cameron McCormack wrote:
> > Boris Zbarsky:
> >> Right.  Olli is talking about the slowdown when an
> >> operation there is a listener for happens.  So if
> >> you're listening for DOMAttrModified, any attribute
> >> change (including foo.style.* changes).
> >
> > Could a solution to this be to allow listeners to be
> > registered (somehow; the DOM Events model doesn't
> > support this at the moment) for particular attributes?
>
> That would help with modifications to other attributes,
> sure, but it wouldn't help with modifications to the
> attribute for which there are listeners.
>
> It also wouldn't help with any other DOM mutations (e.g.
> inserting and removing children).

Many applications using mutation events will be receiving
more events than they are interested in, and will have to
do their own "filtering" to find the interesting events.
Cpu cycles will be wasted both in browser implementation
and page scripts dealing with these unwanted events.

I agree with Cameron that it sounds interesting to be able
to specify/filter events on a finer level already when
subscribing to them.
If we assume that we were able to specify this filtering in
some general way for all mutation types, would this make
enough difference in performance to be an interesting
option?

And if the answer above is yes, could the general
mechanism for specifying filters be based on CSS selectors
and find synergies with querySelectorAll in the Selectors
API?

Best regards
Mike Wilson

[François REMY]

From: "Mike Wilson" <mikewse@...>

> (...)
>
> If we assume that we were able to specify this filtering in
> some general way for all mutation types, would this make
> enough difference in performance to be an interesting
> option?
>
> And if the answer above is yes, could the general
> mechanism for specifying filters be based on CSS selectors
> and find synergies with querySelectorAll in the Selectors
> API?

I agree with you. We should be able to filter events we want to receive.
But CSS Selectors have problem : we can't match an attribute or a text node,
only an HTMLElement.

XPath seems here more appropriate, though we can provide CSS Selectors too,
as additional solution.

Regards,
Fremy