Re: Speeding up mutation events

On 6/4/09 11:08 AM, Boris Zbarsky wrote:
> 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.

Thanks for this explanation. Would it be worthwhile figuring out which, 
of all the possible old values a consumer of DOMAttrModified might be 
interested in, in the wild? Then take this list and flesh out the 
performance vs value, and agree on a subset?  There are, for example 
some aria-* attributes that would be great to have old values for. We 
might want to do this even if we go with an alternative to DOM events 
(see Jonas above). And actually, gathering information about what 
attributes matter would also help if we went the route of adding new 
API.  Maybe a new addEventListener that takes more parameters...

Having old data for CharacterDataChanged events would allow better live 
region support for assistive technology... not sure how to avoid the 
string copy there...

cheers,
David

Received on Thursday, 4 June 2009 15:47:14 UTC