xsl-list
[Top] [All Lists]

Re: [xsl] XSLTPROC performance

2007-12-21 03:11:55
Giulio Rizzo wrote:

Load data from database, data in user defined cache.

That's something that shouldn't be done with an XSLT processor, especially not when performance is an issue. If possible for your system I recommend exporting the data as XML and loading it with document() functions into your XSLT process. If you do need database access (and you don't or can't care about the huge performance overhead with JDBC or ODBC or whatever), you may consider the database extension instructions that come with Saxon (though they are pretty basic: http://www.saxonica.com/documentation/sql-extension/intro.html)

Maybe I'm doing something wrong in the test because execution time of xalan is 10 time the one of xsltproc. It sound strange to me.

You'll find that, when you test and when you test thoroughly, and while meanwhile speeding up your XSLT stylesheets with carefully placed keys etc, that some processors will run thousands of times slower (or faster). So 10 times is not strange, no ;)

Yes, we would like to move to another xslt processor only if there is a faster xslt processor that xsltproc

This highly depends on your stylesheet and how you measure.

The fastest XSLT 1.0 processor around is, arguably, the .NET XSLT processor, part of XML.NET (there's a comparison page on the web, but I couldn't find it anymore). But performance can be hard to measure. Taken XSLT 2.0, Dimitri found out in his blog that statements about this can be very untrue: http://dnovatchev.spaces.live.com/Blog/cns!44B0A32C2CCF7488!325.entry

I found out myself that performance can differ a lot based on a couple of keys. With Saxon this runs in less than a second (originally minutes), with Altova I killed the process after two days of running....: http://www.experts-exchange.com/Web_Development/Web_Languages-Standards/XSLT/Q_22850559.html

Note that this was an optimisation question where changing the XSLT speeded up the process more than 200x!


Saxon seems as slow as xalan. Maybe I'm wrong here too.
I must say that we don't have big xslt or big xml, but a lot of small xslt (max 300 rows) and small XML.

Often, people measure the timing including the startup of the JVM. If you use Saxon properly, you keep the classes and the compiled stylesheets in memory. You'll see that this will improve your performance a lot, especially when talking about many small XML files.

To actually help you with the performance it is best if you give one of your worst-performing XSLT stylesheets so we can have a look in how to optimize it. For instance if you have any constructs like "//nodename", or nested for-each with "//node-name" you are likely to find these proper candidates for optimization.

According to some, btw, the fastest processor is Ambrosoft's Gregor: http://www.ambrosoft.com/performanceresults.htm. I never tried it, but you may give it a go to see how well it performs for you.

Oh, and here's another (PXSLT from Infonyte): http://www.infonyte.com/en/xslt_benchmark.pdf (but again, not tested myself and I don't know whether the JVM startup is taken or not taken into account).

Cheers,
-- Abel Braaksma

--~------------------------------------------------------------------
XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list
To unsubscribe, go to: http://lists.mulberrytech.com/xsl-list/
or e-mail: <mailto:xsl-list-unsubscribe(_at_)lists(_dot_)mulberrytech(_dot_)com>
--~--