Re: [xsl] processing improvements questions regarding document, parameters

Subject: Re: [xsl] processing improvements questions regarding document, parameters
From: "cutlass" <cutlass@xxxxxxxxxxx>
Date: Wed, 17 Apr 2002 10:26:46 +0100
Hello Bryan,

each XSLT processor will have their own strategies for optimisation;

some 1st order observations;

- document() calls should be placed within a global param, after some code
forensics of most of the major processors, and some rather seat of the pants
benchmarking, this say overall better general performance ( the proc doesnt
have to instantiate another tree representation in memory of the doc
! )....with the caveat that very quickly the benefits rapidly become
negatives with respect to the size of document ! so if u are dealing with
rather small xml docs, this is the way to go.

- if you are accessing an xml document with http protocol, there is some
additional overhead, which has a network performance component.

- if your xml document is big..... you may have to use SAX, or break the xml
into smaller chunks..... or use the switches available in the particular
processor

- if you are having some performance issues related with the size and
complexity of your XSLT, compile it with XSLTC.

- distribute processing off server to client ( which i think has something
to do with the 2nd part of your question )

- replace your // with /

- make sure your code runs on a machine with 4 2.2 gigahertz processors with
4 gigs RAM.

these suggestions are most likely very obvious to you !

all other questions seem to me second order in nature, and require a 'try
it' approach and benchmark ( and tell us your results ! ) .

gl, jim fuller

----- Original Message -----
From: "Bryan Rasmussen" <bry@xxxxxxxxxx>


>
>
>
> >With all performance questions, the best answer is "try it and see" --
> >there might sometimes be general guidelines but the majority of the
> >time the differences are so miniscule you should be choosing whatever
> >gives you the easiest maintenance and extensibility rather than the
> >approach that's ever so slightly faster.
>
> was afraid that would turn out to be answer. :)
> Thanks
>
>  XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list
>


 XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list


Current Thread