[XSL-LIST Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: follow up re: key execution speed

Subject: Re: follow up re: key execution speed
From: tcn@xxxxxxxxxxxxx (Trevor Nash)
Date: Fri, 10 Aug 2001 15:17:54 GMT
xsl localization document xsl key
Wild idea: include your zip lookup file in the stylesheet either by
external entity reference or xsl:include (in the latter case you have
to put a stylesheet element in the zip file).  In both cases you will
have to invent a namespace for it.

This *may* be enough to convince Xalan that its the same document
every time rather than a new one, hence it will only rebuild the index
when you prepare the stylesheet.  I believe Saxon can be made to
behave this way, but Xalan may be different.

If I were you I think I would write a simple Java class to read the
zip table and access it from an extension function.  Its not
difficult, and the memory footprint will be less than a tenth of the
XSLT method.

Trevor Nash

>I wrote in last week and received much good advice on using keys to perform
>lookups during XSL execution.  I was advised, properly I am sure, that keys
>are damn fast and the best way to do nearly anything.  However my problem is
>a little unusual, and is resulting in unsatisfactory performance.
>The trick is this: while I have been advised that keys are speed for any
>lookup that will be performed more than once in a transform, my situation is
>a little more complicated. I only do this lookup once per transform, but I
>perform this transform many times (thousands!) on different source
>documents.  I was hoping to get the speed benefit of the key across these
>multiple transformations.
>My XSL templates make use of two data files, Zips.xml, which maps zip codes
>to dealer codes, and Dealers.xml, which contains information about each
>dealer. The idea is to use a key (ziptorc) over the (very large - 400K) Zips
>file (looks like <ZIP zip='10001' rc='2'/>) to perform the zip-to-dealer
>mapping, then to use another key over the dealer file (rctodealer) to
>perform a generic templating of the dealer informaiton. My templates are as
><xsl:key name="ziptorc" match="ZIP" use="@zip"/>
><xsl:key name="rctodealer" match="DEALER" use="@rc"/>
><xsl:template name="TARGETBYZIP">
>	<!-- target by ZIP -->
>	<xsl:variable name="ZIP">
>		<xsl:value-of select="ZIP/@val"/>
>	</xsl:variable>
>	<xsl:variable name="RC">
>		<xsl:for-each select="document('Zips.xml')">
>			<xsl:value-of select="key('ziptorc', $ZIP)/@rc"/>
>		</xsl:for-each>
>	</xsl:variable>
>	<xsl:for-each select="document('Dealers.xml')">
>		<xsl:apply-templates select="key('rctodealer', $RC)"/>
>	</xsl:for-each>
><xsl:template match="DEALER">
>	<!-- generic template for displaying dealer information here -->
>I am using Xalan, creating and persisting a Templates object. I am then
>creating a Transformer object to perform each transform. Performance is very
>slow; seems to me that it is reloading the data files and recreating the
>keys every time it performs the transform.
>Is there some set of changes, to the XSL or to the Java, that will enable me
>to get the blazing performance I require?
>Thanks very much for your help.
> XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list

Traditional training & distance learning,
Consultancy by email

Melvaig Software Engineering Limited
voice:     +44 (0) 1445 771 271 
email:     tcn@xxxxxxxxxxxxx

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

Current Thread


Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
First Name
Last Name
Subscribe in XML format
RSS 2.0
Atom 0.3
Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.