W3C home > Mailing lists > Public > public-webapi@w3.org > April 2007

Re: ElementTraversal spec draft

From: Stewart Brodie <stewart.brodie@antplc.com>
Date: Tue, 3 Apr 2007 17:28:32 +0100
To: public-webapi@w3.org
Cc: bzbarsky@mit.edu
Message-ID: <e0ff101268f0fb6711eecc98fb92e3b460b8eccc@localhost>

Boris Zbarsky <bzbarsky@MIT.EDU> wrote:

> Doug Schepers wrote:
> > Sure, on a established code base for a desktop browser, that makes
> > sense.  But on mobile devices with limited memory, maintaining a live
> > list is more overhead.
> I agree that it can sometimes be more processor-intensive, depending on
> the exact usage pattern.  But maintaining a live list means that you don't
> actually have to have anything in the list until someone asks, which in
> practice means lower memory overhead for long-ish lists.  In fact, even if
> someone asks, you could drop the nodes from the list on memory-pressure
> notifications, and recreate the list as needed...
> Note that live lists can even be a processor win, depending on how the
> page accesses them.  Gecko only looks through the DOM as little as it can
> get away with, so if you do getElementsByTagName("foo")[0] it'll stop
> after it finds the fist node.  This was actually a huge CPU win over
> walking the whole DOM in some cases, in addition to being a memory win.
> I guess my issue is that I think that for typical web usage (in my
> experience, etc) live lists can actually take up less memory and
> comparable CPU...  But then again, I've spent a good bit of time on
> Gecko's live NodeList implementation to get it to this point.  ;)

As a fellow implementor of NodeList (and HTMLCollection and NamedNodeMap),
I'd agree with all that.  My implementation is targetted at devices that
have limited CPU power and memory resource.  Maintaining live lists is less
overhead, but you just have to be more clever about how you implement those
classes.  It is possible to create extremely efficient implementations of
these for slow, memory-limited devices - you just need to be careful about
tree updates.  It is also quite easy to create extremely inefficient
implementations :-)

I'd say that the same goes for most of the DOM Core levels 1 and 2, and DOM
HTML Level 2 interfaces.

> P.S.  The Gecko implementation _is_ open-source and algorithms aren't
> subject to copyright last I checked, so anyone who wants to set up things
> similarly can. They'll need a notification infrastructure, but they need
> that anyway to handle changes to the DOM, I would think.

Aren't those DOM events handy?  Just what you need to keep these data
structures up to date.   It sounds like you do exactly the same as me :)

Stewart Brodie
Software Engineer
ANT Software Limited
Received on Tuesday, 3 April 2007 16:27:44 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:16:23 UTC