CachedXPathAPI performance hit?

[garyh6 <gh...@fetch.com>]

We recently switched an app from using XPathAPI to CachedXPathAPI and saw
huge performance improvements, especially on documents with large amounts of
Nodes (makes sense).  However, we have recently found the same application
has slowed down somewhat when applied to a different set of documents, which
have much smaller amounts of Nodes.  We have not finished profiling, but
there is some preliminary evidence pointing to CachedXPathAPI.

Obviously reusing CachedXPathAPI is a performance gain, but is there an
overhead in the cases where it can’t be reused?  Specifically, we throw out
the CachedXPathAPI whenever the DOM is modified, which depending on the
data, could lead us to using the CachedXPathAPI just once before discarding. 
In this scenario, can CachedXPathAPI be slower than XPathAPI?  Or should
they perform equivalent?

-- 
View this message in context: http://www.nabble.com/CachedXPathAPI-performance-hit--tp24963297p24963297.html
Sent from the Xalan - J - Users mailing list archive at Nabble.com.

Re: CachedXPathAPI performance hit?

[garyh6 <gh...@fetch.com>]

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.

Re: CachedXPathAPI performance hit?

[ke...@us.ibm.com]

I would expect CachedXPathAPI to perform about as well as XPathAPI -- the 
main difference is that it requires explicit clean-up to release the 
cached copy of the document. But it's been a while since I looked at that 
code.

______________________________________
"... Three things see no end: A loop with exit code done wrong,
A semaphore untested, And the change that comes along. ..."
  -- "Threes" Rev 1.1 - Duane Elms / Leslie Fish (
http://www.ovff.org/pegasus/songs/threes-rev-11.html)