Arnaud Le Hors wrote: > > Yep, NodeLists are really bad for performance. Definitely use the > > getFirstChild/getNextSibling paradigm. > > Beware, this assertion is true for Xerces but it may be false for other > implementations though. > In xerces children are stored in a linked list, so getNextSibling is > clearly the winner. On the other hand, with an implementation where > children would be stored in an array, using the NodeList interface would > be better.
Surely it's the fact that NodeLists are 'live' that's the real killer -- when I remove a node that would have been in the list, the list (maybe) has to be regenerated (from scratch?). I'm sure there's lots of clever ways to speed up NodeLists, and that they've been done already in the Xerces code. But if I traverse the NodeList, remember nodes I want to remove, set the NodeList to 0 so it doesn't have to update itself (is this necessary if the NodeList is going to go out of scope without me accessing it again?) and then remove all the nodes I originally wanted to, surely that's going to be faster than having a live NodeList update itself, however well it's implemented. Things are complicated by, for example, NodeLists obtained with getElementsByTagName() which contain all descendants, rather than immediate children. All of this is speculation on my part, because I haven't read the relevant Xerces code that implements it. When (if) I get some time I'll run a few benchmarks on really small pieces of code to see how different methods compare (NodeLists, TreeWalker, custom getNextSibling() code, etc). Best regards, Mike. -- Mike Mason, Software Engineer XML Script Development Team Office: 44-1865-203192 http://www.xmlscript.org/ Mobile: 44-7050-288923
