Subject: RE: [xsl] Slower performance of compiled stylesheets with Saxon on poor hardware? From: "Michael Kay" <mike@xxxxxxxxxxxx> Date: Tue, 21 Feb 2006 12:42:44 -0000 |
> our server happens to be rather old and poorly equipped with > RAM (and there is a database and a lot of other stuff running > on it). So I tried compiled stylesheets to improve the > performance of the XSLT transformation (Solaris with saxon8b) > and got the rather odd result that compiled stylesheets took > 2 to 4 seconds longer than the transformation with the > uncompiled stylesheet (i.e. 10-12 for the uncompiled and > 13-15 for the compiled stylesheet. > Saxon-specific questions would be better asked on the Saxon list (saxon-help list or forum at SourceForge). Yes, compiled stylesheets in Saxon are not a great success story. In fact, many people misunderstand what they are. Saxon handles stylesheet processing in two phases, a "compile-time" phase which generates an internal representation of the stylesheet, and a "run-time" phase that interprets the code in this internal representation to transform a source document. The only thing that the "Compile" command does is to write the internal representation to disk, as a serialized Java object. At run-time, the behaviour is exactly the same. There are two possible reasons for wanting to do this: for a performance benefit (because loading the code from the serialized representation is faster than recompiling from scratch), or for IPR protection: to obfuscate the source code and prevent users modifying it. Making the internal code serializable also means that application servers can relocate it from one server to another. As you observe, the deserialization often takes as long as the original compilation, and sometimes longer (largely because there is more data to be read from disk), so the performance benefits are not compelling. I suspect that your performance results may be for a single-shot compilation run from the command line. The costs here are dominated by Java start-up time. To convince yourself of this, run with the undocumented -3 option, which runs the transformation thrice, and see how much faster the second and third runs are. The best way of improving performance in such cases is to re-use the Java VM rather than starting it from fresh each time. If you don't want to write your own Java calling harness, you might consider Andrew Welch's EasyTransformer front-end. Michael Kay http://www.saxonica.com/
Current Thread |
---|
|
<- Previous | Index | Next -> |
---|---|---|
Re: [xsl] Slower performance of com, andrew welch | Thread | [xsl] Adding rowspans to a table, Kevin Bird |
Re: [xsl] Slower performance of com, andrew welch | Date | Re: [xsl] RSS transform, Jon Gorman |
Month |