- From: Olli Pettay <Olli.Pettay@helsinki.fi>
- Date: Mon, 04 Jul 2011 19:57:18 +0300
- To: Ojan Vafai <ojan@chromium.org>
- CC: Boris Zbarsky <bzbarsky@mit.edu>, public-webapps@w3.org
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. > -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