XSLT 2.0 and XPath 2.0 Programmer's Reference, 4th Edition (360 page)

Fortunately, it's quite rare in practice for both operands to be sequences of more than one item. This case can get very expensive, though there are plenty of ways an XPath processor can avoid actually doing M × N comparisons. It's made more complicated by the fact that the conversion rules apply separately to each pair of items. This means that if you have the comparison
@a
=
(12
,
“pineapple”)
, where the node
@a
is untyped, then the untyped value has to be converted to a number to be compared with the number 12, and to a string to be compared with the string
“pineapple”
. In the general case, it isn't possible to do all the conversions upfront, before starting the pairwise comparison.

The more type information you can supply at compile time, the more likely it is that the XPath processor will actually know in advance that it doesn't have to deal with these complications, because they can't actually arise. For example, if you are writing a function in XSLT that has a parameter
$p
, and the function contains the test
if
($p=3)
then
...
, then declaring the parameter as an
xs:integer
(if that's what it is) can make a world of difference—if you don't declare its type, then the processor is going to have to assume the worst, which is that it might be an arbitrary mixture of typed nodes, untyped nodes, integers, strings, dates, and anything else the caller of the function cares to throw at it. But if you declare it as an
xs:integer
then the compiler can quietly replace the complex
=
operator with the much simpler and presumably faster
eq
operator. Alternatively, if you know that
$p
will be an integer, you can write the expression using the
eq
operator directly.