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

[Mike Trotman <mike trotman datalucid com>]

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.


Mike


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.
>
>                 Jirka
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> xslt mailing list, project page http://xmlsoft.org/XSLT/
> xslt gnome org
> http://mail.gnome.org/mailman/listinfo/xslt
>  

--
Datalucid Limited


Message Scanned by ClamAV on datalucid.com