Re: Optimizing a XSLT

Hi Eric,

I believe your performance issue is in the code below. With a 32k test input 
file (based on your original) this template is responsible for approx 80% of 
the evaluation cost on the processor I use. 

>  <xsl:template name="unit">
>    <xsl:choose>
>     <xsl:when test="unit=preceding::unit">
>      <xsl:choose>
>       <xsl:when test="schedule=preceding::schedule">
>        <xsl:call-template name="PricePointProcess"/>
>       </xsl:when>
>       <xsl:otherwise>
>        <xsl:call-template name="NewUnit"/>
>        <xsl:call-template name="PricePointProcess"/>
>       </xsl:otherwise>
>      </xsl:choose>
>     </xsl:when>
>     <xsl:otherwise>
>      <xsl:call-template name="NewUnit"/>
>      <xsl:call-template name="PricePointProcess"/>
>     </xsl:otherwise>
>    </xsl:choose>
>  </xsl:template>

The problem is the use of preceding::unit and to a slightly lesser extent 
preceding::schedule. Both of these searches require a complete document scan 
backwards from the current node. As the template is called for each ROW in 
your input this is a lot of searching. 

You could probably improve things slightly by using preceding-sibling, 
something like,	"unit=../preceding-sibling::ROW/unit" but that would only be 
a minor improvement. 

A better solution when you expect large inputs that you need to search in this 
way a lot is to use a key. Something like this should suffice,

<xsl:key name="unitKey" match="unit" use="."/>

<xsl:when test="generate-id(unit) != generate-id(key('unitKey',unit)[1])">

On my 32k input file this was twice as quick using the key approach and 
processed a 1Mb file in significantly less than a minute.

Kev.


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