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
