This is the mail archive of the
xsl-list@mulberrytech.com
mailing list .
Re: processing improvements questions regarding document, parameters
- From: "cutlass" <cutlass at secure0 dot com>
- To: <xsl-list at lists dot mulberrytech dot com>
- Date: Wed, 17 Apr 2002 10:26:46 +0100
- Subject: Re: [xsl] processing improvements questions regarding document, parameters
- References: <DCEPIHHFOCEMDBGBKIOPKEKNCGAA.bry@itnisk.com>
- Reply-to: xsl-list at lists dot mulberrytech dot com
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@itnisk.com>
>
>
>
> >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