Re: Mutation events replacement

On Mon, Jul 4, 2011 at 9:57 AM, Olli Pettay <Olli.Pettay@helsinki.fi> wrote:
> 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 <bzbarsky@mit.edu
>> <mailto: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?)
>
> 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.

I think both of these can be a single "ChildlistChanged" mutation (not
a batch of mutations).

>
>
>> -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 Tuesday, 5 July 2011 21:23:53 UTC