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