After some more testing, it appears that CachedXPathAPI does perform equivalent to XPathAPI, at least for our test data. However, we found something interesting -- the CachedXPathAPI constructor is not cheap. On my machine, calling it 10000 times in a loop took 5.5 seconds. This was surprising to me since the constructor does not accept a DOM so no parsing is going on. I assumed the constructor created a lightweight shell object, and that the only heavy work was done on the first use of CachedXPathAPI, when it needed to parse the DOM and save it for future reference. But I looked at the source and there is a bunch of stuff being allocated.
I am not saying this is extraneous work not done by XPathAPI -- as mentioned before our tests showed they performed equivalently when CachedXPathAPI was used only once and discarded. And of course, CachedXPathAPI has huge benefits when re-used. However, if you are creating lots of CachedXPathAPI objects, then making sure to use lazy initialization and creating only when actually used could save some time. -- View this message in context: http://www.nabble.com/CachedXPathAPI-performance-hit--tp24963297p24975078.html Sent from the Xalan - J - Users mailing list archive at Nabble.com.
