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 |
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).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
Is it likely that I would get any performance advantage from using the S9 API ?
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.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
Michael Kay Saxonica
Current Thread |
---|
|
<- Previous | Index | Next -> |
---|---|---|
[xsl] Re: Saxon performance differe, Fraser Goffin | Thread | [xsl] string set difference, Andriy Gerasika |
[xsl] Re: Saxon performance differe, Fraser Goffin | Date | Re: [xsl] Markers in tables and fo:, charlieo0 |
Month |