Re: ElementTraversal spec draft

Hi-

The issue of live vs. static lists is actually orthogonal to my main 
question (though that would be a relevant argument to bring to the 
Selectors spec, which uses a static list... I think that ship may have 
sailed, though).

The functionality I was requesting primary feedback on was whether or 
not to include an interface in the ElementTraversal spec which would 
provide a list of elements (not nodes, which could include spaces and 
line breaks, etc.) that are children of the context element.

This would be a shorter list (using a bit less memory), would let 
authors know the number of elements before stepping into the loop 
(preventing them from having to loop twice through the same list to get 
that info, which you need to make best use of available space for 
positioning and sizing), and would let the authors bypass the irritating 
check for nodeType.

Regards-
-Doug

Stewart Brodie wrote:
> 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 :)
> 
> 


-- 

Regards-
-Doug

Research and Standards Engineer
6th Sense Analytics
www.6thsenseanalytics.com
mobile: 919.824.5482

Received on Tuesday, 3 April 2007 16:51:01 UTC