Last updated $Date: 2006-03-20 10:21:01 +0000 (Mon, 20 Mar 2006) $ $Author: goetzger $
XSL performance, xmlBlaster uses XT
An article about XML performance
The following is from the XSL mailing list:
===========================================
Eight tips for how to use XSLT efficiently:
1. Keep the source documents small. If necessary split the document first.
2. Keep the XSLT processor (and Java VM) loaded in memory between runs
3. If you use the same stylesheet repeatedly, compile it first.
4. If you use the same source document repeatedly, keep it in memory.
5. If you perform the same transformation repeatedly, don't. Store the
result instead.
6. Keep the output document small. For example, if you're generating HTML,
use CSS.
7. Never validate the same source document more than once.
8. Split complex transformations into several stages.
Eight tips for how to write efficient XSLT:
1. Avoid repeated use of "//item".
2. Don't evaluate the same node-set more than once; save it in a variable.
3. Avoid if you can. For example, by using position().
4. Use , for example to solve grouping problems.
5. Avoid complex patterns in template rules. Instead, use
within the rule.
6. Be careful when using the preceding[-sibling] or following[-sibling]
axes. This often
indicates an algorithm with n-squared performance.
7. Don't sort the same node-set more than once. If necessary, save it as a
result tree fragment
and access it using the node-set() extension function.
8. To output the text value of a simple #PCDATA element, use
in preference
to .
Mike Kay
Date: Wed, 19 Jan 2000 14:52:40 +0100
From: "WYSOCKI Adalbert"
Subject: RE: Processor Performance
I performed some tests resumed above:
Tests on XSLT processors
------------------------
The main point to evaluate in order to decrease the processing time applying
style rules to an XML document is to choose the best XSL Processor
associated with the best XML parser. I mean the processor that have the best
conformance with regards to XSLT recommendations and that processes style
sheets as fast as possible and as regularly as possible. For that we have
performed some test with each processor with different XSL documents and XML
documents to reflect different possible cases. Results are resumed in the
following paragraph.
Tested processors
-----------------
- - XT version Version 19991105 (the reference) written by James Clark
implementing the last recommendations(http://www.jclark.com)
- - Saxon Version 5.0 written by Mike Kay implements the last recommendations
(http://users.iclway.co.uk/mhkay/saxon)
- - Xalan v0.19.1 processor known in the past as Lotus XSL (It have been
offered by IBM to an open source apache XML project
(http://xml.apache.org)).
- - Oracle v2_0_2_6 processor part of Oracle 8i database product.
Enviromnent
-----------
- - PC Pentium III 500
- - 256 Mo
- - Windows NT 4.0 Server
- - JDK 1.2.2 (+ JIT)
Results
-------
For each test given results are:
- - An average on times get from the test performed 60 times
- - The minimum value from 60 times
- - The maximum value from 60 times
*********
* Test1 *
*********
Documents:
- - XML document: stats.xml (8ko)
- - Style document: statistics_list.xsl (47ko)
-----------------------------------------------------------------------------------------------------------------------
|Processeur | XT + Xerces | XT + SUN | Saxon + Xerces | Saxon + SUN | Xalan + Xerces | Oracle + Oracle |
-----------------------------------------------------------------------------------------------------------------------
|Average (ms) | 54.58333333 | 51.75 | 108.6333333 | 159.9 | 151.7167 | 169.75 |
|Min (ms) | 20 | 20 | 50 | 90 | 80 | 140 |
|Max (ms) | 350 | 421 | 610 | 851 | 932 | 1101 |
-----------------------------------------------------------------------------------------------------------------------
*********
* Test2 *
*********
Documents:
- - XML document: stats2.xml (21ko)
- - Style document: statistics_list.xsl (47ko)
Changes: contracts BO with class="display" attribute has been increased by
10 so that the matching of this BO in the XSL style sheet is made 10 times
more that in the preceding case.
-----------------------------------------------------------------------------------------------------------------------
|Processeur | XT + Xerces | XT + SUN | Saxon + Xerces | Saxon + SUN | Xalan + Xerces | Oracle + Oracle |
-----------------------------------------------------------------------------------------------------------------------
|Average (ms) | 165.2 | 220.8 | 368.55 | 419.1 | 552.8 | 422.1 |
|Min (ms) | 110 | 140 | 281 | 320 | 400 | 270 |
|Max (ms) | 650 | 670 | 962 | 1182 | 1592 | 1472 |
-----------------------------------------------------------------------------------------------------------------------
XSLT Rules
----------
I have performed some tests changing, replacing and inverting rules in XSL
style sheets.
We found a rule (use absolute path instead of //) that makes documents
processing 10 times quickly.
Resulting XSL documents will be processed in less than 100 ms. I think it is
satisfying comparing to database requests processing time.
C/C++ vs. Java
--------------
Processors in C language are not yet available in general. The XSLT
recommendations are in most part based on the Java language especially
concerning some functions like those for number formatting or some others.
For those reasons their implementation in C language seems to be more
difficult than in Java. I have tested Xalan XSLT processor in its first
version. A lot of XSLT functionalities are not yet implemented and its debug
mode makes it process very slowly. I think to see very efficient XSLT
processor we have to wait some times.
Results of the test performed on the summary.xsl and summary.xml documents.
------------------------------------------
|Processor | XT Java | Xalan C++ |
------------------------------------------|
|processig | 500 | 2000 |
|time (ms) | | |
------------------------------------------
XT processor DOM source or serialized DOM InputSource
-----------------------------------------------------
-------------------------------------------------
| Serialized | Login | Summary | Stats |
| InputSource | page | page | page |
|-------------------------------------------------|
| | 40 | 240 | 130 |
| | 40 | 230 | 160 |
| | 40 | 260 | 120 |
| | 30 | 230 | 140 |
| | 40 | 240 | 120 |
| | 30 | 240 | 121 |
| | 40 | 240 | 100 |
| | 30 | 230 | 120 |
| | 60 | 270 | 120 |
| | 41 | 270 | 110 |
|-------------------------------------------------|
| Average | 39.1 | 245 | 124.1 |
-------------------------------------------------
-------------------------------------------------
| DOM Object | Login | Summary | Stats |
| | page | page | page |
|-------------------------------------------------|
| | 40 | 571 | 171 |
| | 30 | 521 | 130 |
| | 30 | 491 | 271 |
| | 40 | 430 | 130 |
| | 30 | 400 | 130 |
| | 41 | 401 | 140 |
| | 40 | 411 | 130 |
| | 30 | 390 | 120 |
| | 30 | 401 | 140 |
| | 40 | 400 | 130 |
|-------------------------------------------------|
| Average | 35.1 | 441.6 | 149.2 |
-------------------------------------------------
We can see that XT runs in general case better with a serialized InputSource
document that with a DOM object.
Conclusions
-----------
Comparing to the fastest other XSLT processors XT is two times quickly. What
is important too is the difference between the behavior of the XT and Saxon
processor associated with from one part ProjectX parser (SUN) and from the
other part with Xerces parser (xml apache project).
===============================================================================
===============================================================================
Date: Fri, 21 Jan 2000 10:29:25 -0000
From: Kay Michael
Subject: RE: XSLT processors performance/compliance matrix
A few performance tips off the top of my head. I suspect they are likely to
apply to most processors.
- - Keep the patterns in template rules simple, use conditional logic within
the template rather than having hundreds of different rules to be matched.
Especially avoid positional predicates in patterns, e.g. .
- - Use "/descendant::*" in preference to "//*". The latter, if implemented
naively, is interpreted as /descendant-or-self::*/child::*, which finds all
descendant elements of the root, then finds their child elements, then sorts
the result into document order. The former finds all the descendant elements
of the root directly, and they probably don't need to be sorted. The two
constructs are equivalent provided there is no positional predicate.
- - Use position() in preference to wherever possible.
- - Many of the algorithms for solving grouping problems in XSLT have
n-squared or even n-cubed performance. If you need to do grouping on a large
data set, consider preprocessing it first to add extra element nodes around
the groups. You can do this preprocessing with a simple SAX filter, or by
using proprietary XSL extensions such as SAXON's .
- - If you are transforming many source documents, especially if they use the
same stylesheet, control the process using the vendor's proprietary API,
rather than writing a script that runs each one from the command line. The
initialisation time fror getting the Java VM running and loading all the
classes can dominate the actual stylesheet execution cost.
===============================================================================
===============================================================================
Date: Mon, 8 May 2000 16:04:14 -0500
From: mkoss@us.britannica.com
Subject: RE: XLST Processors Performace
I have only tested XT and Saxon, but between the two, XT seemed to be the
only one that could handle more than 4 concurrent requests. If
multithreading is an issue for you, then go with XT.
===============================================================================
===============================================================================
Date: Tue, 9 May 2000 00:18:01 +0100 (BST)
From: "Sebastian Rahtz"
Subject: Re: XLST Processors Performace
Carlos Sanchez writes:
> Has anyone done benchmark performance testing of the different XSLT [java]
> processors (XALAN, XT, Saxon, etc...) over "big" XML files? I imagine the
> transformation time depends on the size of the source file and the
> complexity of the XSL among others.
I keep trying to run benchmarks on a biggish XML file (3 mbytes,
making repeated lookups of a second 700k file), but
I can only get Saxon and XT to even finish the job. Oracle and Xalan
are close, but just not quite there yet (I am sure their next releases
will run my file).
whenever I run timings, there is no contest. XT always wins. But the
last Saxon release (5.3.1) is now sufficiently close to XT that I have
started to use it for all my work, since XT is incomplete.
obviously, the other XSLT processors (MS, Oracle C version, the
gingerall one), however laudable in some ways, simply lack all the
necessary language features.
Sebastian Rahtz
===============================================================================
HOME