Re: [xslt] key() in match pattern of xsl:key
- From: Mike Trotman <mike trotman datalucid com>
- To: The Gnome XSLT library mailing-list <xslt gnome org>
- Subject: Re: [xslt] key() in match pattern of xsl:key
- Date: Mon, 12 Dec 2005 02:50:41 +0000
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
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]