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 |
---|
|
<- Previous | Index | Next -> |
---|---|---|
[xsl] performace considerations for, Leena Kulkarni | Thread | Re: [xsl] performace considerations, Leena Kulkarni |
Re: [xsl] get the xsl:variable in a, Jarkko . Moilanen | Date | Re: [xsl] get the xsl:variable in a, John Barden |
Month |