Re: Mutation events replacement

On Mon, Jul 4, 2011 at 6:43 PM, Boris Zbarsky <bzbarsky@mit.edu> wrote:
> 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.

Just to be clear here (since there's been some discussion of a flag
which would cause "fine-grain" notifications) -- I don't believe
there's any need to describe *more* mutations. I.e. My proposal is
*not* to record more than one mutation record for a call to innerHTML
which affects more than one element. That case would still be a single
'ChildlistChanged' mutation. This is a key part of Jonas's proposal
that we want to keep: It is (I think) optimally succinct, while still
containing (nearly -- see below) all the bits of information that you
need.

I.e. The set of mutation records during any given event should be more
or less on the order of the number of DOM *operations* -- not affected
nodes. Also note that it seems like the multiple observers can share
the same mutation record (just like multiple event listeners share the
same event object).

The question is how much data is contained in the mutation record.
Here's my sense:

For ChildlistChanged, the potential data to be included:
-Target node*
-Removed nodes*
-Added nodes
-one of nextSibling or previousSibling*

My belief is that including the starred (*) data above would be
sufficient to meet David's test of mirroring a tree *without* a ton of
processing or O(N) memory.

If people think it's worth while seeing example js code that
implements this properly and it'll convince the group that this data
is sufficient, I'll sign up for implementing it.

>
>> 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 21:21:45 UTC