Re: [xslt] key() in match pattern of xsl:key

I did some XSLT speed comparisons earlier this year on xsltproc, saxon 6,3 and msxsl 3.0 and 4.0.
I compared xsltproc and saxon on Linux and windows on several, large, complex XSLT transformations
(transforming a 100mb document consisting of hundreds of large data cubes into an alternative structure.)
I tried to eliminate the time for loading and parsing the XSLT + XML documents from the time required to do the processing.

The two main machines were a 3gHz XP PC with 1gB ram and a RHlinux server with twin 1gHz processors and 512mB ram.

msxsl 4.0 was generally faster - sometimes 4 times faster - but, like all XSLT processors,
there were large variations in accomplishing the same XSLT task depending on how the XSLT was written (similar to SQL implementations).
Generally msxsl 4.0 was uniformly the best performing - with xsltproc coming 2nd.
Saxon gave the largest fluctuations in performance ( 300%) depending on how the XPATH expressions were written.
The most sensitive areas seemed to be Xpath expressions using relative paths (e.g. '../element/something or other').

One particular task caused all 3 processors to use all available memory and hang.
When re-written to use Saxon's preview extension this process would probably have taken over 168 hours (based on estimates from 48 hours processing).
When rewritten using a different XSLT approach and the 'document' element to split output the task ran using xsltproc and Saxon in under an hour,
with xsltproc slightly (approx 5%) faster.
(msxsl does not support the 'document' element.)

In no cases did I find Saxon faster than xsltproc - when not using processor specific features.

So I think speed comparisons can only be made for specific Xpath / operations on specific machine configurations,
but can be very informative for optimising XSLT in general and for specific processors.

A general comparison of processors - particularly when they implement different features (and exsl functions) is probably meaningless.


Jirka Kosek wrote:

Joel E. Denny wrote:

I've never used Saxon myself. I've read that libxslt is one of (or the) fastest XSLT 1.0 processor around. Maybe this is one of the reasons?

With the respect to Daniel and its work, my experience is that libxslt is very fast when XSLT code doesn't contain "complex computations". This is case for the most of common stylesheets that are around. But I have several stylesheets that do various cases of a very complex grouping and Saxon is faster by magnitude then libxslt here. But for common transformations libxslt is faster because there is no JVM overhead.

In general, MSXML 4.0 is usually the fastest, but it runs only on Windows. Recently MS released MSXML 6.0 and there could be further speed optimizations.

Anyway if the performance is your main objective, you should benchmark several XSLT implementations and then choose your favorite implementation.

You can also try to optimize your XSLT code, xsltproc offers very useful --profile option to do this.

Back to your question, as keys are computed only once for the source document, there shouldn't be big performance penalty if you just remove key() from other keys' definitions.



xslt mailing list, project page
xslt gnome org

-- Datalucid Limited

Message Scanned by ClamAV on

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]