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

RE: XSL Optimizations

Subject: RE: XSL Optimizations
From: "Didier PH Martin" <martind@xxxxxxxxxxxxx>
Date: Sat, 19 Jun 1999 23:36:15 -0400
xsl optimizations
Hi Lars,

an unchecked instruction is the "select" instruction. usually this construct
is costly. If the grove (hoops sorry, the document tree :-), so if the
document tree is based on multi map ( a la STL) then the research time is
reduced a lot and the result of a select query is a lot accelerated.

regards
Didier PH Martin
mailto:martind@xxxxxxxxxxxxx
http://www.netfolder.com

-----Original Message-----
From: owner-xsl-list@xxxxxxxxxxxxxxxx
[mailto:owner-xsl-list@xxxxxxxxxxxxxxxx]On Behalf Of Lars Marius Garshol
Sent: Sunday, June 20, 1999 8:54 AM
To: xsl-list@xxxxxxxxxxxxxxxx
Subject: Re: XSL Optimizations



* Jon Smirl
|
| I'm curious, do any of the current XSL implementation use the input
| document's DTD/schema to reduce the number of templates that must be
| checked as each node is visited? Any ideas if this optimization
| would improve the processing speed very much?

I doubt that this would achieve much of a speed-up since the
information about which nodes a pattern will match is probably best
gleaned from the pattern itself. (Also, DTDs/schemas are not always
available and may well be costly to analyze in their own right.)

An idea that has been floating around in my head is to have a hash
table that maps element type names to a list of templates that may
match elements of the given type.

Another, and rather more ambitious idea is to turn patterns upside
down and have a map from element type names to patterns that may match
some descendant of that element type. Patterns can then be added to
and removed from this list on the way down the tree and patterns
invoked when their last requirement has been satisfied.

However, nice though it may sound, I doubt that the last technique
will actually save more than it costs. Also, chances are that the real
costs of XSL processing lie elsewhere than in the matching of patterns
(at least for non-pathological stylesheets). I'd do a thorough
profiling of an XSL engine before setting to work to eliminate
bottlenecks in it.

--Lars M.


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


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


Current Thread

PURCHASE STYLUS STUDIO ONLINE TODAY!

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.
Email
First Name
Last Name
Company
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.