CachedXPathAPI differs from XPathAPI in that it holds its document models
(or document model adapters, if you're searching a DOM) in memory between
XPath evaluations. This means you skip a lot of set-up work.
The majory downside, of course, is that retaining this data structure ties
up memory.
A secondary disadvantage is that, since this model doesn't track changes to
the source data, the cache can cause erroneous results if you alter the
document between queries; it's your responsibility to keep track of when
such changes might have occurred and to flush the cache (by discarding the
CachedXPathAPI object and obtaining a new one) before your next XPath
search.
(There was an experiment in progress to try to create a compromise adapter
-- the DOM2DTM2 class -- which *would* track changes to the source DOM, at
the cost of being less performant. Due to some impedence mismatch issues
between the DOM and DTM APIs, this would work only for DOMs which had
uniquely hashable Node objects, which limited its applicability, and it was
set aside in favor of the XDM idea, which itself has been somewhat stalled
due to other time commitments.)
Basically: If you use CachedXPathAPI, pass it a DOMSource, and remember to
discard and recreate this set-up every time the DOM has changed between
XPath calls, all the right things should happen.
______________________________________
Joe Kesselman, IBM Next-Generation Web Technologies: XML, XSL and more.
"The world changed profoundly and unpredictably the day Tim Berners Lee
got bitten by a radioactive spider." -- Rafe Culpin, in r.m.filk
