[XSL-LIST Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] 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
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|