[XSL-LIST Mailing List Archive Home] [By Thread] [By Date]

Re: [xsl] XSLTPROC performance

---

---

Thanks for the reply

> > I am required to write some extension function to a libxml compliant xslt
> > processor.
>
> May I ask you what this extension function is about? Often people write
> extension functions when the same thing is possible with a little extra
> effort within XSLT itself .

Load data from database, data in user defined cache. 


> > (performance is the highest
> > requirement),
>
> If this is true you shouldn't use XSLT and XML in the first place.
> Clarity and extensibility have always been higher requirements for these
> languages (and its tools) then performance. I.e., a SOAP bridge (which
> is based on XML) is inherently slower than a RPC bridge (or most other
> alternatives like CORBA and DCOM).

The entire system is based on xslt stylesheet, we are trying to see if there 
is a way to speed up the system. Actually I'm trying using xalan but it seems 
so much slower than xsltproc. Maybe I'm doing something wrong in the test 
because execution time of xalan is 10 time the one of xsltproc. It sound 
strange to me.

> > Is any other solution alternative to the two I've mentioned? The problem
> > is that is about 6 years that XSLTPROC have been used and the new (?)
> > processor must give the same results as XSLTPROC.
>
> There are plenty XSLT 1.0 processor around. If your stylesheets are
> written without using extensions, you can reckon that they are quite
> likely XSLT 1.0 compliant and will run with the same results on most
> processors (whitespace, which is insignificant in XML, not counted). Of
> course you'll have to test this to be sure. There are XML comparison
> tools around that will find differences that are significant.

Yes, we would like to move to another xslt processor only if there is a faster 
xslt processor that xsltproc

> > Last question, the optimum will be to be able to use a java XSLT
> > processor, but I must be sure that it is 100% compliant with the results
> > of an XSLTPROC execution on the same input.

> One of the most used XSLT processors these days is the Saxon processor
> (but that's a gut feeling). The older Saxon 6.5 processor (not
> maintained anymore) is 100% XSLT 1.0 compliant and supports many of the
> EXSLT extensions. The newer Saxon 9.0 processor is 100% XSLT 2.0
> compliant. Going to XSLT 2.0 may give you a little trouble in the
> beginning, but many things that were formerly done with extension
> functions or complex recursion have become one-liners in XSLT/XPath 2.0.
> Of interest to you might be the XSLT 1.0 backward compatibility mode
> which makes running XSLT 1.0 code easier.

Saxon seems as slow as xalan. Maybe I'm wrong here too.
I must say that we don't have big xslt or big xml, but a lot of small xslt 
(max 300 rows) and small XML.

regards.

Giulio

---