Support #1379
closed
Performance problem with Saxon 8.3
0%
Description
SourceForge user: dpirkle
In upgrading from Saxon 7.3.1 to 8.3, I noticed that
some of our stylesheets were running significantly
slower with the new version. I've attached some
doctored XSLT and XML files that demonstrate this.
When I run the stylesheet named perf1.xsl using the
7.3.1 version of Saxon, it takes about 0.8 seconds to do
the transformation of perf.xml on my computer. Using
the 8.3 version with the same stylesheet and data, the
transformation takes about 10.2 seconds. It appears
that the evaluation of the xpath expression on line 23
accounts for most of this time. I also noticed that with
Saxon 8.3, if I use saxon:evaluate to evaluate the xpath
expression, the performance improves significantly from
10.2 to 1.5 seconds. You can see this by running the
stylesheet perf2.xsl. All the files are in the attached zip
file.
Files
Updated by Anonymous about 19 years ago
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.
Updated by Anonymous about 19 years ago
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.
Please register to edit this issue
.