Re: Mutation events replacement

On 7/4/11 12:28 PM, Ojan Vafai wrote:
> I'm not sure there really is a performance tradeoff. I believe that the
> proposal Rafael put forward should almost always be faster. Storing the
> list of changes and doing a JS callback once, for nearly all use-cases,
> should be faster than frequent, semi-synchronous callbacks.

That depends on whether your list of changes gets big enough that your 
start swapping, for example.

> The only bit that might be slower is what data you include in the
> mutation list.

That's one of the things that could get slower, yes.  It's not the only one.

> -The index of the child that changed for ChildListChanged (is this
> actually expensive?)

It could be.  In Gecko's case it's cheap right now because kids are 
stored in arrays, but WebKit uses doubly linked lists with a cache of 
some sort for indices last I checked.  So for some access patterns this 
could be pretty expensive in WebKit.

> -The old value of an attribute/text node. I know this is expensive in
> Gecko's engine at least.

This can be expensive in all engines, if they do it right.  Consider 
having to serialize out values of the 'style' attribute (possibly twice) 
on every .style.foo set.  Or having to serialize out path attributes as 
the SVG DOM is mutating paths.  This is not a Gecko-specific issue.

> I'd be fine with excluding that information by default, but having a
> flag you pass at some point saying to include those. That way, only
> sites that need it take the performance hit.

This would be a lot more palatable to me, yes.  This brings us back to 
having ways to ask for different levels of detail in mutation notifications.

-Boris

Received on Tuesday, 5 July 2011 01:43:57 UTC