JXPath is designed to work with heterogeneous models, including JavaBeans, Maps, Collections etc, as well as DOM, JDOM, etc. To accomodate all this variety, JXPath inevitable produces some overhead. For example it creates a bunch of NodePointer objects during the evaluation of an XPath. You wouldn't need such objects if you only worked with XML (DOM, JDOM). Thus, JXPath is slower than for instance Xalan, which manages to allocate almost zero objects.
I am currently working on some behind-the-scenes integration between JXPath and Xalan. Once that's complete, JXPath performance will be similar to that of Xalan, as long as you are working exclusively with XML. I hope this helps. - Dmitri --- Snehal Khanna <[EMAIL PROTECTED]> wrote: > We are in the process of evaluating two > implementations of XPath namely JXPath and jd.xpath > from www.aztecrider.com > > In our evaluations we have noticed that for XPath > expressions resulting in a node set with 100 nodes, > the performance of jd.xpath is superior to the > performance of JXPath. It looks like JXpath loses out > on performance while iterating through the results. > > For XPath expressions resulting in a single node > output, the performance is comparable if we use > compiled expressions. > > Has anyone else performed a similar analysis? Are > there any known performance issues with JXPath that > are currently being addressed? In general what is the > development plan for JXPath in terms of performance > improvements and enhancements? > > Regards, > Snehal > > > __________________________________ > Do you Yahoo!? > Yahoo! SiteBuilder - Free web site building tool. Try it! > http://webhosting.yahoo.com/ps/sb/ > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
