Subject: RE: XSL Optimizations From: "Didier PH Martin" <martind@xxxxxxxxxxxxx> Date: Sat, 19 Jun 1999 23:36:15 -0400 |
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 |
---|
|
<- Previous | Index | Next -> |
---|---|---|
Re: XSL Optimizations, Lars Marius Garshol | Thread | Re: XSL Optimizations, Jon Smirl |
RE: release of FOP, Didier PH Martin | Date | RE: Re FOP release, Didier PH Martin |
Month |