I'm experiencing bad performance with certain kinds of match queries. Using
a custom XPathNavigator that wraps the usual navigator I can see that many
more node visits are performed than should be required. My document looks
something like this:
<a>
<b>
<c/>
</b>
<b/>
<b/>
<!-- many more "b" elements here -->
</a>
I have a navigator positioned at the first "b" element. If I run the query
nav.Matches( "a/b[c]" ), only three nodes are visited in order to complete
the query. However, the query nav.Matches( "a/b[1]" ) visits *all* the
nodes in the document before it returns! I can understand perhaps why the b
nodes above the current position should be visitied to obtain the index of
the current element, but why visit anything after the current position?!
For example the query nav.Matches( "b[1]" ) visits only three nodes.
I believe I am once again getting stung by
System.Xml.XPath.MergeFilterQuery, which for some reason scans the entire
document for hits before returning the first one. Suprisingly it does this
in MatchNode() as well as advance()! Does anyone know MergeFilterQuery is
designed to do, and how it differs from FilterQuery? What is the reasoning
behind caching the list of hits?
Steve.