Subject: Re: [xsl] Optimizing a XSLT From: Kevin Jones <kjones@xxxxxxxxxxx> Date: Mon, 14 Apr 2003 20:56:16 +0100 |
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
Current Thread |
---|
|
<- Previous | Index | Next -> |
---|---|---|
Re: [xsl] Optimizing a XSLT, Mike Haarman | Thread | RE: [xsl] Optimizing a XSLT, Michael Kay |
[xsl] Cocoon and XSL, nshah | Date | [xsl] Update Variables..., McCown, Sean |
Month |