xsl-list
[Top] [All Lists]

Re: performace considerations for XSL while coding

2003-04-06 21:39:57
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(_at_)sarvega(_dot_)com> 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



<Prev in Thread] Current Thread [Next in Thread>