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

Subject: Re: [xsl] Re: Saxon performance difference in eClipse and App Server
From: Michael Kay <mike@xxxxxxxxxxxx>
Date: Thu, 16 Dec 2010 10:39:20 +0000
On 16/12/2010 09:29, Fraser Goffin wrote:
MK>  Beware of phrases like "native language performance advantage". You're
MK>  making assumptions, and assumptions are often wrong unless they're
MK>  backed up by measurements.

Yes you're absolutley right. But I *do* have measurements that using
the language of the integration platform (its called eSQL in this
case) *is* more performant than running the equivalent transformation
using XSLT
Yes, but you have no information that supports a diagnosis that this difference can be attributed to "native language performance advantage". You need to keep a completely open mind about the reason for the difference. It may be that the SQL programmer was more experienced than the XSLT programmer. It may be because there are costs being incurred in the XSLT pipeline that are not directly related to XSLT (I saw one example where the costs were all in user-written Java code creating the XML input for the XSLT transformation).

Is it likely that I would get any performance advantage from using the S9 API ?

No. s9api was designed to give usability benefits, not performance benefits.
FRG>  I wondered about pre-compiling the stylesheets and caching them
FRG>  instead,

MK>I don't understand the difference - the Templates object is a "compiled"
MK>stylesheet.

I meant, using the java  net.sf.saxon.Compile command line to create
the compiled stylesheet as a pre- execution step and then
No, this won't give you any performance benefits. It can reduce the cost of recompiling the same stylesheet repeatedly by saving the compiled stylesheet to disk, but your problems are nothing to do with compilation time, they are all to do with execution time.

I think my next step would be to look at a Java execution profile of the transformation running in the two different environments, and see if there are any differences that stand out.

But I'd also be looking at requirements. What performance do you actually need from this transformation? Are you within sight of it? Will doubling the transformation speed actually make any difference to the bottom line? Is there any reason for believing that the application architecture you have chosen is capable of delivering the performance required?

Michael Kay
Saxonica

Current Thread