Subject: Re: [xsl] performace considerations for XSL while coding From: Leena Kulkarni <mulberrylist@xxxxxxxxxxx> Date: Mon, 7 Apr 2003 05:39:57 +0100 (BST) |
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
Current Thread |
---|
|
<- Previous | Index | Next -> |
---|---|---|
Re: [xsl] performace considerations, Kevin Jones | Thread | Re: [xsl] performace considerations, David Carlisle |
[xsl] XSLT lexical scanner and pars, martin | Date | RE: [xsl] XML/XSL Validator, Jarno . Elovirta |
Month |