- From: Rafael Weinstein <rafaelw@google.com>
- Date: Tue, 5 Jul 2011 14:21:10 -0700
- To: Boris Zbarsky <bzbarsky@mit.edu>
- Cc: Ojan Vafai <ojan@chromium.org>, public-webapps@w3.org
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