Cart
|
[XSL-LIST Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: XSLTPROC performance
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. 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 
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! 
Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|
