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