Re: Mutation events replacement

On 07/04/2011 07:28 PM, Ojan Vafai wrote:
> 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 <
> <>> 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?)

You may need more than just an index. element.innerHTML = null removes
all the child nodes.
And element.inserBefore(some_document_fragment, element.lastChild)
may insert several child nodes.
Depending on whether we want to get notified for each mutation
or batch the mutations, simple index may or may not be enough.

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

Mutation listener could easily
implement old/new value handling itself, especially if it knows which
attributes it is interested in.

> 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

Received on Monday, 4 July 2011 16:57:44 UTC