Saxon

SourceForge user: mhkay

Logged In: YES

user_id=251681

Thanks for reporting it, and for providing such a convincing

demonstration of the problem. I have reproduced the problem

and will investigate it.

SourceForge user: mhkay

Logged In: YES

user_id=251681

You can recover the performance by writing the expression as

$root//A/B/C (which is what your saxon:evaluate version does).

What's happened here is that the Saxon optimizer has become

more cautious about rewriting path expressions. This is

because there are (unusual) cases where the "/" operator in

XPath 2.0 is not associative, and the optimizer was getting

these wrong, by rewriting ((A/B)/C) as (A/(B/C)) in cases

where this was incorrect. In XPath 1.0, "/" is always

associative.

The important optimization here is that with the expression

//A, Saxon saves the result the first time it is executed,

and re-uses the result on subsequent occasions. With your

expression as written, the preconditions for this

optimization are not all satisfied, but if it changes to

$root//A then (for completely arbitrary reasons) they are.

You can get far better performance improvements here by

avoiding the use of //A entirely, and using keys.

I will use this test case to tweak the optimizer so that

this rewrite is invoked with your expression as written.

This change will appear in a future release.