Re: [xsl] performace considerations for XSL while coding

Subject: Re: [xsl] performace considerations for XSL while coding
From: Kevin Jones <kjones@xxxxxxxxxxx>
Date: Fri, 4 Apr 2003 10:44:34 +0100
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.


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


Current Thread