I've used JXPath with much success, however I've never really done any performance metrics. I would imagine that underneath, it's using reflection to navigate through the object heirarchy.
This seems destined to be slower than executing Xpath queries against a static XML stream.
The nice thing about JXPath is that the interface stays the same, whether you're querying an XML file or a Java object tree underneath. This could allow you to switch your strategy if you notice any performance problems.
[EMAIL PROTECTED] wrote:
Since I did not get any answers, I am wondering if I am missing something and if my question make sense. What I am trying to understand if that if I have two implementation choices:
1) JXPath on top of Java objects
Or
2) Java objects -> XML serialized -> Xpath with something like Xalan
What will be faster/better? I am sure that it will depend on the complexity of the Java object/XML tree as well as the kind of Xpath queries, but I am wondering if anyone did any kind of performance testing in this area.
Thanks.
Thomas
-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] Sent: Sunday, November 23, 2003 10:51 AM
To: [EMAIL PROTECTED]
Subject: [JXPath] Performance
I did a couple of searches in the mailing list and on the web to try to et performance information on JXPath. I did not find too much result, so I am asking the question directly to the mailing list. Anyone is any kind of performance numbers/comparisons between JXPath and other Xpath processors that they could share?
More specifically, here is what I am looking for. Assuming that I have an application processing XML documents. This application manipulates XML documents themselves (string and DOM representation) as well as a Java bean object tree representing those documents (typed/dedicated tree for each type of document). If I need to do some Xpath processing on those documents, what will be the fastest: using something like Xalan to apply Xpath on the DOM tree or using something like JXPath on the java bean object tree?
Thanks.
Thomas
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
