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

Subject: [xsl] Re: Saxon performance difference in eClipse and App Server
From: Fraser Goffin <goffinf@xxxxxxxxx>
Date: Thu, 16 Dec 2010 09:29:13 +0000
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 but ... I want to see how close I can get to that such that
*other* advantages of using XSLT may in some cases influence our
implementation choice. When the difference was as it was when I first
looked at this (50ms (eSQL) versus 700ms (XSLT)) the choice was clear.
Now it is 50ms vs 150 it is less so.

I am trying to remove the '..simple avoidable mistakes' that you
(rightly) mention.

This code is being used for ALL XSLT processing in this particular
application. That is, developers specifiy the stylesheet and provide
the input XML only.

The XSLT a developer creates can obviously have a significant impact
on performance, and it that sense its the equivalent of writing the
corresponding transformation in eSQL. We are addressing that issue
separately.

What I am trying to do is ensure that the general code used for
*executing* XSLT it is as efficient as it can be.

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

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

sheet = PreparedStylesheet.loadCompiledStylesheet(config, styleFileName)

in the code ?

Am I mis-understanding this too ?

Thanks for you patience

Fraser.

Current Thread