[XSL-LIST Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: processing improvements questions regarding docume

Subject: Re: processing improvements questions regarding document, parameters
From: "cutlass" <cutlass@xxxxxxxxxxx>
Date: Wed, 17 Apr 2002 10:26:46 +0100
order processing improvements
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

PURCHASE STYLUS STUDIO ONLINE TODAY!

Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
Email
First Name
Last Name
Company
Subscribe in XML format
RSS 2.0
Atom 0.3
Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.