- From: Boris Zbarsky <bzbarsky@MIT.EDU>
- Date: Tue, 03 Apr 2007 11:06:04 -0500
- To: Web API public <public-webapi@w3.org>
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