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

Subject: Re: [xsl] Saxon performance difference in eClipse and App Server
From: Michael Kay <mike@xxxxxxxxxxxx>
Date: Wed, 15 Dec 2010 17:19:59 +0000
On 15/12/2010 16:56, Fraser Goffin wrote:
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.
Yes, that's progress. I'm afraid I don't know why you're still seeing a difference. Other than perhaps that Eclipse is running without other concurrent processes sharing the resources?
I would now like to see if there is any further improvement possible
by using Saxon's native tree
With a StreamSource, that's what you're using.

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,
I don't understand the difference - the Templates object is a "compiled" stylesheet.

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)
I suspect that's discussing use of XSLTC which compiles down to bytecode?

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.
It's always hard to do performance engineering properly via Q&A on a forum like this. Answering your question professionally needs a deep understanding of the systems architecture and the workload requirements. Having said that, performance is full of contradictions - good performance depends on good top-down system design, but bad performance is often caused by a simple avoidable mistake somewhere in the system where someone didn't understand enough about the technology they were using - e.g. your use of DOMSource.

Beware of phrases like "native language performance advantage". You're making assumptions, and assumptions are often wrong unless they're backed up by measurements.

Michael Kay
Saxonica

Current Thread