[xsl] Re:Slower performance of compiled stylesheets with Saxon on poor hardware=

Subject: [xsl] Re:Slower performance of compiled stylesheets with Saxon on poor hardware=
From: "cavecatem@xxxxxxxxxxxxx" <cavecatem@xxxxxxxxxxxxx>
Date: Wed, 22 Feb 2006 13:43:14 +0100
Date: Wed, 22 Feb 2006 13:36:05
Message-ID: <08EC07D602160C24052B5@xxxxxxxxxxxxx>
MIME-Version: 1.0
X-Priority: 3 (Normal)
Content-Type: text/plain;
Content-Transfer-Encoding: quoted-printable
X-CUSTOMER: 00000000

Hi Michael,

> Saxon-specific questions would be better asked on the Saxon list=20
> (saxon-help
> list or forum at SourceForge).
Thanks for the tip, I missed that.
> Yes, compiled stylesheets in Saxon are not a great success story. In fa=
> many people misunderstand what they are.=20
Could be. Frank Bongers in his book on XSLT 2.0 states that using compile=
d stylesheets reduces the processing time by a factor of 2 to 3.
Naturally, that idea made me very happy ;-)

But as long as it's not definitely slower, I prefer the compiled styleshe=
et because they are not so easy to read by humans, so they'll rather show=
 up asking for a different stylesheet instead of copying mine, editing it=
, and then calling four times a day because theirs doesn't work.
> I suspect that your performance results may be for a single-shot=20
> compilation
> run from the command line. The costs here are dominated by Java start-u=
> time. To convince yourself of this, run with the undocumented -3 option=
Yes, with the -3 option, the compiled stylesheet wins ;-)=20

> third runs are. The best way of improving performance in such cases is =
> re-use the Java VM rather than starting it from fresh each time. If you

Unfortunately, I don't see how this would be possible. The transformation=
s will be carried out on demand to show current data, triggered by a scri=
But I'll keep it in mind.

Many thanks for your help.

Current Thread