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 <[EMAIL PROTECTED]> 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
