RE: [xsl] using mode in multiple template match conditions will improve speed?

Subject: RE: [xsl] using mode in multiple template match conditions will improve speed?
From: "Michael Kay" <mike@xxxxxxxxxxxx>
Date: Thu, 3 May 2007 22:01:04 +0100
> using mode in multiple template match 
> conditions will improve speed?

It's very hard to offer advice about performance except in relation to a
specific XSLT processor. Constructs that are optimized in one might not
necessarily be optimized in another.

And even then, the only real way to tell is to make measurements. Sometimes
A is faster than B, but if B only accounts for 0.1% of your execution time,
then it hardly matters.
> 
> 
> 1. whether using MODE like <xsl:apply-templates mode="MC"/> 
> at the start and <xsl:template 
> match="ANSWER[@QTYPE='MC']/CHOICE" mode="MC"> at the 
> receiving side will speed up things? - Assuming this will 
> stop checking every template to find the matching condition.

It's hard to imagine an implementation in which using a mode like this would
slow things down. On the other hand, there's no guarantee it will speed
things up.
> 
> 2. Can I replace multiple choose-when by doing something like?
> 
> 	<xsl:template match="ANSWER">
> 		<div>
> 			<xsl:attribute 
> name="class">q_<xsl:value-of select="@QTYPE"/></xsl:attribute>
> 			<xsl:apply-templates/>
> 		</div>
> 	</xsl:template>
> 
> 	where the div class name is now set dynamically.

Yes, you can. Or even 

<div class="{@QTYPE"}><xsl:apply-templates/></div>
> 
> 3. If yes to point (2), will adding translate will offset any 
> gains? - I mean as a better practice, i may have to use 
> translate to convert class names q_MC to q_mc even though css 
> i believe is case in-sensitive or update my css from q_mc to 
> q_MC - but this has other practical problems.

Well, there are many ways of optimizing a call on translate(), especially
when the 2nd and 3rd arguments are known statically; and there are many ways
of optimizing a sequence of <xsl:when> conditions of the form
test="@a='abc'", test="@a='def', test="@a='ghi', etc. So it all depends on
what your chosen XSLT vendor has chosen to optimize.

I think these examples fall into the category: if you've got a performance
problem, this kind of tweaking is unlikely to solve it; and if you haven't
got a performance problem, then why are you worrying about it?

Michael Kay
http://www.saxonica.com/

Current Thread