Re: ElementTraversal spec draft

Doug Schepers wrote:
> Accidentally sent offlist to Boris.

I was wondering.  ;)

> 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.


> Also, I know of at least one SVG viewer implementor who complained about having
 > to create live nodelists from scratch.

I guess SVG doesn't require support for getElementsByTagName, does it?

> ElementTraversal started as an interface for resource-restricted
> devices, and I want it to continue to work for them.

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.  ;)

-Boris

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.

Received on Tuesday, 3 April 2007 16:06:21 UTC