Saxon

Compiling the query

declare variable $doc external;  $doc/descendant-or-self::node()/child::node()

with the -explain option, both 9.8 and 9.9 fail to deliver this optimization.

Looking at how the original stylesheet is optimized in 9.8.

SlashExpression docOrder(($doc1) treat as node()/descendant-or-self::node())/child::node()

The LHS turns into ConditionalSorter(exists(tail(($doc1) treat as node())), docOrder(($doc1) treat as node()/descendant-or-self::node()))

DocumentSorter line 108 turns the SlashExpression (of which the above is the LHS) into ConditionalSorter(exists(tail(($doc1) treat as node())), docOrder((($doc1) treat as node()/descendant-or-self::node())/child::node()))

that is, it has moved the final /child::node step inside the ConditionalSorter, which paves the way for the descendant-or-self and child steps to be combined (which happens in SlashExpression.simplifyDescendantPath(), line 287)

The 9.9 optimization path also succeeds in folding the final child::node() step inside the ConditionalSorter, but it seems that the final simplifyDescendantPath() never happens.

Comparing the 9.8 and 9.9 optimization paths step-by-step, 9.8 having optimized the whole template body, goes into global variable extraction (which succeeds) and then does another optimization pass on the result. 9.9 has optimizer options set which inhibit global variable extraction, and the second optimization pass therefore doesn't happen. It's the second pass that recognizes the opportunity to simplify the descendant axis.

The Configuration is initializing a defaultXsltCompilerInfo during its init sequence, at a point where the variable optimizerOptions holds the optimizer options for Saxon-HE; the value is subsequently changed to the set of options appropriate to Saxon-EE, but this is too late to affect the default XSLT compiler info object.

This causes 9.9 to generate essentially the same code as 9.8 for this example stylesheet.

However, this leaves open the question why two optimization passes should be needed to optimize this particular construct, and why it doesn't get optimized in the simple case of the direct query given in comment #1.

The issue here seems to be that SlashExpression.simplifyDescendantPath is called during the type-checking phase, and is not called again during the optimization phase. So if optimization generates an expression that is amenable to this rewrite, it won't normally happen, unless we go back to repeat the type-checking, which is normally not encouraged.

Putting another call on simplifyDescendantPath() into the optimize phase solves the problem.

I won't do this for 9.8, however, in the interests of stability.