Execution speed is a property of the XSLT implementation, not a property
of the language. You can't ask questions about performance without
saying what processor you are interested in.
With a trivial source document like this, it is very unlikely that any
performance difference will be measurable.
If there were a million B elements, some processors might (with either
expression) count all the elements and then ask whether a million is
equal to one. Other processors might (with either expression) stop at
the second element and realize that the count is not going to be equal
to one. So different processors might give very different performance
from each other (with either expression), varying by a factor of a million.
But then, if you parsed the source document containing a million B
elements, it's likely that parsing the document would take a lot longer
than counting the elements, so the performance difference including
parsing cost might not be so big after all.
If there were more than one A element, the two expressions would not be
equivalent, so asking whether one is faster than the other is
irrelevant. One of them will give the wrong answer.
Assuming you know there will always be one A, I would think that the
most consistent performance across processors would be achieved by
writing not(Document/A/B[2]). Of course, there's still a possibility
that a very naive processor would construct a node-set containing all
the nodes in Document/A/B, and then select the second of these nodes.
There are no limits to human stupidity.
Michael Kay
Saxonica
On 19/09/2012 14:34, Costello, Roger L. wrote:
Hi Folks,
Consider this XML document:
<Document>
<A>
<B>blah</B>
</A>
</Document>
Here are two XPath expressions to test that there is exactly one <B> element in the <A> element (assume there is only one <A> element):
1. count(/Document/A/B) eq 1
2. /Document/A/(count(B) eq 1)
Which is faster?
Is there an XPath expression, besides the ones listed, that is even better and faster?
/Roger