Re: [xsl] Saxon performance difference in eClipse and App Server

Subject: Re: [xsl] Saxon performance difference in eClipse and App Server
From: Fraser Goffin <goffinf@xxxxxxxxx>
Date: Wed, 15 Dec 2010 16:56:08 +0000
Michael/Andrew,

thanks for the advice. Moving away from using a DOMSource to a
StreamSource has cut the App Server times from 700-800ms to 150-180ms,
so that was really worthwhile.

It also has a similar effect to the [same] code when I run it in
eClipse, which now shows an average time of around 50ms.

I'm still not sure why there remains a 3 to 4 times overhead for
running the same code but at least in actual terms things are much
better.

I would now like to see if there is any further improvement possible
by using Saxon's native tree as per Micael's suggestion (a hint to get
me going would be helpful - do you mean using the S9 API (per the
examples you provide ?)

As you can see I use Templates since the XSLT is relatively stable and
is executed 000's of times with different source XML (its always XML
to XML transformation in this case).

I wondered about pre-compiling the stylesheets and caching them
instead, but I am slightly wary because of comments I have seen in
other threads about how these might be specific to the version of the
processor (ie. not guaranteed to be backwards compatible) ... and that
it *may* not make much difference (although I guess perfromance is
always about impirical results rather than guesses).

What I am really trying to get to the bottom of here is whether the
native language perfromance advantage of the integration platform that
we are using is significant enough to suffer the need to recompile and
redeploy larger parts of the application when changes are needed, or
whether we can get adequate enough perfromance out of using XSLT and
benefit from a less disruptive and potentially more flexible change
capability. All of our messages are XML, and I kinda like the idea of
using XML oriented processing tehnologies ... but maybe I'm just being
stubborn.

Regards

Fraser.

Current Thread