xsl-list
[Top] [All Lists]

Re: Optimizing a XSLT

2003-04-14 12:56:16

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



<Prev in Thread] Current Thread [Next in Thread>