Re: Mutation events replacement

Apologies in advance if my comment makes no sense. This is a long thread, I
tried to digest it all. :)

On Sat, Jul 2, 2011 at 7:07 AM, Boris Zbarsky <bzbarsky@mit.edu> wrote:

> That may be ok, if the use cases that incur this cost are rare and the
> common case can be better served by a different approach.
>
> Or put another way, if 1% of consumers want the full list because it makes
> them 4x faster and the other 99% don't want the full list, and the full list
> is 3x slower for the browser to build than just providing the information
> the 99% want, what's the right tradeoff?
>

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.

The only bit that might be slower is what data you include in the mutation
list. I believe that all the data you'd need is cheap except for possibly
the following two:
-The index of the child that changed for ChildListChanged (is this actually
expensive?)
-The old value of an attribute/text node. I know this is expensive in
Gecko's engine at least.

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.


> The numbers above are made up, of course; it would be useful to have some
> hard data on the actual use cases.
>
> Maybe we need both sorts of APIs: one which generates a fine-grained change
> list and incurs a noticeable DOM mutation performance hit and one which
> batches changes more but doesn't slow the browser down as much...
>
> -Boris
>
>