XPathNavigator, Attribute predicate evaluation

[SteZgr]

I have implemented in .NET 2.0 a custom XPathNavigator for Xpath filtering
on an object tree. So far it works. While analyzing the performance, I have
noticed a lot of MoveToNextAttri bute calls.

A closer look has shown that there seems to be a none optimal evaluation of
attribute predicates such as [@ID = '2']. It works as expected if there is a
match of the attribute value, i.e. the XPathNavigator calls
MoveToNextAttri bute until it gets the ID attribute, reads the value and
finish the search.

The behaviour is different if the value if the ID attribute does not match
the value in the predicate. Then the XPathNavigator calls
MoveToNextAttri bute until it returns false, i.e. until all attributes are
checked. From my point of view, the search for attributes could be stopped
if there is a match of the attribute name as the attribute names for a node
must be unique.

Stop the search if the attrbute name matches would improve the performance
by factors. In my data model, there are about 20 attributes. Most the
filters are using the ID attribute. By placing the ID attribute at the first
position in the collection, the potential performance gain is a factor of
20.

[dave.dolan]

I'm nobody of authority, but I'd say you have an excellent point there!

Since you've implemented a navigator in 2.0, do you find that there is
anything that would need to be done differently than one in 1.1? I have done
a couple in 1.1, and since I'm just getting familiar with 2.0 proper I really
don't know all of the ways in which I could improve my performance with it..
I have read that the xmlnametable implementation is better, but that's all I
have so far...

Any tips?

"SteZgr" wrote:

I have implemented in .NET 2.0 a custom XPathNavigator for Xpath filtering
on an object tree. So far it works. While analyzing the performance, I have
noticed a lot of MoveToNextAttri bute calls.

A closer look has shown that there seems to be a none optimal evaluation of
attribute predicates such as [@ID = '2']. It works as expected if there is a
match of the attribute value, i.e. the XPathNavigator calls
MoveToNextAttri bute until it gets the ID attribute, reads the value and
finish the search.

The behaviour is different if the value if the ID attribute does not match
the value in the predicate. Then the XPathNavigator calls
MoveToNextAttri bute until it returns false, i.e. until all attributes are
checked. From my point of view, the search for attributes could be stopped
if there is a match of the attribute name as the attribute names for a node
must be unique.

Stop the search if the attrbute name matches would improve the performance
by factors. In my data model, there are about 20 attributes. Most the
filters are using the ID attribute. By placing the ID attribute at the first
position in the collection, the potential performance gain is a factor of
20.