[jdom-interest] newbie question
Robert Koberg
rob at koberg.com
Wed Dec 4 06:59:46 PST 2002
Hi again and thanks for your answer,
> -----Original Message-----
> From: Laurent Bihanic [mailto:laurent.bihanic at atosorigin.com]
> Sent: Wednesday, December 04, 2002 6:35 AM
> Robert Koberg wrote:
> > Is there something about JDOM that makes XPath in Java much better
> performing
> > than using DOM? Or by using XPath do you have the same problems
> (memory) that
> > you have with DOM?
>
> I agree that XPath is probably not the fastest (CPU-wise) solution but why do
> you think XPath can lead to memory problems?
I did not know that is why I asked :) I am relatively new to JDOM. As for
memory, I was curious if XPath in JDOM needed to create a DOM (or DOM-like??)
structure to be able to access any and all nodes. I am very comfortable with
XPath, but I have been avoiding it in JDOM, thinking iterating > recurse >
iterate > recurse etc would be better. Or, if the XML is simple enough, just do
something like:
String myattr =
doc.getRootElement().getChild("aaa").getChild("bbb").getAttributeValue("myattr")
;
Is there some way to do something like xsl:key to set up access points and use
XPath's key() to retrieve the value or nodeset(if nodeset is the correct term
here)?
> The XPath engine allocates memory when it compiles the XPath expression (when
> you invoke XPath.newInstance) but not when evaluating the expression
> against a
> given node. At this stage, it just navigates the document.
> There's one exception to the above rule in Jaxen: Namespaces. When evaluating
> namespaces, the XPath engine allocates wrapper objects as XPath Namespaces do
> have a parent while JDOM's don't.
>
> As for speed, you can reach quite good performances by compiling XPath
> expressions and reusing them (i.e. using XPath.newInstance rather than the
> static selectNodes and selectSingleNode). If need be, you can use XPath
> variables in your expressions to use few generic compiled XPaths and call
> setVariable to "adapt" the expression before each evaluation.
OK, cool. Does 'quite good performance' equate to the performance of iterate >
recurse etc? Or is iterate > recurse etc always going to be fastest?
best,
-Rob
>
> Laurent
>
More information about the jdom-interest
mailing list