Project

Profile

Help

Support #1379

closed

Performance problem with Saxon 8.3

Added by Anonymous over 19 years ago. Updated over 12 years ago.

Status:
Closed
Priority:
Normal
Assignee:
-
Category:
Internals
Sprint/Milestone:
-
Start date:
Due date:
% Done:

0%

Estimated time:
Legacy ID:
sf-1164232
Applies to branch:
Fix Committed on Branch:
Fixed in Maintenance Release:
Platforms:

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

perf.zip (9.56 KB) perf.zip Anonymous, 2005-03-16 05:39
Actions #1

Updated by Anonymous over 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.

Actions #2

Updated by Anonymous over 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

Also available in: Atom PDF