Re: NodeList performance (was Re: DOM children problem w/ xerces)

[Michael Mason <mg...@decisionsoft.com>]

Mike Gratton wrote:
> 
> Great, thanks Andy, Arnaud, I really appreciate it. Tell me though, how
> would you recurse through a node's child nodes without using a NodeList?
> With getFirstChild()/getNextSibling?

I've been doing this with a NodeList, but am unsure if it's actually the
best thing to do.

I want to perform these operations:

 1. Grab all nodes called "foo" in the entire document, and remove any
that aren't a child of a particular top-level element "bar" (i.e.
foo.getParentNode() != myBarNode)

 2. Given that all "foo" nodes in the document are now children of
"bar", maintain a list of the foo nodes while I fiddle around with other
nodes in the document, maybe adding extra foo nodes as direct children
of bar.

 3. Finally copy some of the document content that's delimited by foo
nodes, and junk all of the foo nodes.

Depending on how slow NodeList actually is, maybe I should do stage 1 by
maintaining a list of victim nodes as I go through the NodeList, make
sure the NodeList is out of scope (not sure if this makes a difference),
then run over my list of victims removing them from the document.

Maybe stage 2 would be faster if instead of using a NodeList, I used my
own custom list (say vector<DOM_Node&> or something) and updated it
myself when I did inserts and so on.

In stage 3, instead of actually removing the foo nodes, I could nobble
my output serialiser so that it checks each element to see if it's
"foo", and not output and foos.

Is there an answer for any of these questions, or is it better for me to
write the code several different ways and benchmark it myself?

Cheers,
Mike.

-- 
Mike Mason, Software Engineer
XML Script Development Team                    Office: 44-1865-203192
http://www.xmlscript.org/                      Mobile: 44-7050-288923

Re: NodeList performance (was Re: DOM children problem w/ xerces)

[Andy Clark <an...@apache.org>]

Michael Mason wrote:
> In stage 3, instead of actually removing the foo nodes, I could nobble
> my output serialiser so that it checks each element to see if it's
> "foo", and not output and foos.

Unless subsequent processing needs the edited document, perhaps
it would be better to write a tree traverser that ignores the
nodes in question. Hmmm... I like that idea! :)

-- 
Andy Clark * IBM, JTC - Silicon Valley * andyc@apache.org