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.
