Re: performace considerations for XSL while coding

Hello,

Thanks for the reply. It was very useful.

What I understand by your last tip is that
<xsl:variable name="..." select="..."/>
should be preferred. Is that right?

I am using -
<xsl:variable name="..." >
<xsl:copy-of select="...." />
/xsl:variable>

in my code. Do you think this hampers performance?

Thank you in advance!

Leena

 --- Kevin Jones <kjones@xxxxxxxxxxx> wrote: > 
> Hi,
> 
> On Friday 04 April 2003 06:43, Leena Kulkarni wrote:
> > Hi All,
> > What are the performace considerations for XSL?
> What
> > are the points to be kept in mind while 'coding' ?
> >
> > Considerations can be related to the following
> points
> > individually?
> 
> The generic answer to all these types of questions
> is "it's implementation 
> specific" but as that is not very helpfull here are
> some general thoughts 
> based on my experiences. However, the answers are
> going to depend a lot on 
> which processor you use.
> 
> >
> > 1. Use of Variables Vs XPath
> 
> You would expect that the use of a variable would
> make sense if you evaluate 
> the same XPath expression more than once. I have
> recently been looking at 
> this issue and found that for our implementation CPU
> data cache issues mean 
> that the second evaluation of an XPath expression
> will often be much quicker 
> than the first if they are close togeather. In one
> case I looked at you 
> needed at least four uses of an XPath expression
> before it was quicker to use 
> a variable.
> 
> > 2. Use of Call Templates Vs Apply Templates
> 
> Call should always be quicker although the benefit
> is going to depend on how 
> much work has to be done in the apply-templates.
> This is dependant upon both  
> what you are applying templates to and the
> complexity of the match 
> expressions you have on the templates in the
> stylesheet. Having said that if 
> the solution is complex maintainability of the
> stylesheet is normally better 
> with apply-templates.
> 
> > 3. TYpe and no of Param values getting passed
> 
> This is hard to comment on as I think there are
> plenty of ways of handling 
> parameters. In our XSLT implementation the answer is
> virtually no cost for 
> any number of parameters with the exception of when
> a parameter is not 
> supplied and takes a default value. You just have to
> try it and see.
> 
> > 4. Any other?
> >
> 
> There are a lot of issues to consider but a couple
> of my favourites are:-
> 
> String operations - XSLT 1.0 is fairly limited in
> its support for string 
> operations. This can lead to some quite bizarre ways
> of performing string 
> parsing which often have really negative effects. 
> 
> Use of RTF - Using result tree fragments where only
> a select is needed.
> <xsl:variable name="..."><xsl:value-of
> select="..."/></xsl:variable>
> where is far cheaper
> <xsl:variable name="..." select="..."/>
> 
> Kev.
>  

________________________________________________________________________
Missed your favourite TV serial last night? Try the new, Yahoo! TV.
       visit http://in.tv.yahoo.com

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