W3C home > Mailing lists > Public > www-dom@w3.org > April to June 2009

Re: Speeding up mutation events

From: Boris Zbarsky <bzbarsky@MIT.EDU>
Date: Thu, 04 Jun 2009 11:08:18 -0400
Message-ID: <4A27E362.4080102@mit.edu>
To: Jonas Sicking <jonas@sicking.cc>
CC: "www-dom@w3.org" <www-dom@w3.org>, "iestand@microsoft.com" <iestand@microsoft.com>, Travis.Leithead@microsoft.com
Jonas Sicking wrote:
> 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.

The other thing that creates overhead for mutation events is actually 
the information they provide...  For example, DOMAttrModified events 
need to provide the old and new value.  If a browser stores the 
attribute as something other than a string, this involves a 
serialization step.  For example, if I have a JS animation that 
repeatedly sets element.style.top, then on every set a mutation event 
needs to be fired that includes the serialized forms of the element's 
inline style both before and after the mutation.  UAs get this wrong in 
practice in a lot of cases because the performance cost is simply not 
acceptable.  Simiarly, CharacterDataChanged events need to include both 
the old and new string.  Note that this means the event has to make 
copies of both strings (or in some other way acquire references to 
immutable versions of them; might be easier in an environment where 
strings are immutable to start with), since it can't rely on the DOM 
storing the "after" state (and certainly not the "before" state).

This issue is hard to address in practice; in Gecko the internal change 
notification system gets around this by just not providing the 
information...  And it turns out that most consumers really don't need 
it; they just care that a change happened, not what the precise 
before/after values were.

Received on Thursday, 4 June 2009 15:09:12 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 20 October 2015 10:46:14 UTC