[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;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
X-PRIORITY: 3
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.
=20
> Yes, compiled stylesheets in Saxon are not a great success story. In fa=
ct,
> 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.
=20
> 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=
p
> 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 =
to
> 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=
pt.
But I'll keep it in mind.

Many thanks for your help.
CJ

Current Thread