[XSL-LIST Mailing List Archive Home] [By Thread] [By Date]

RE: [xsl] Slower performance of compiled stylesheets with Saxon on poor hardware?


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
Keywords