[XSL-LIST Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: how to estimate speed of a transformation
[ Charset ISO-8859-1 unsupported, converting... ] > > Maybe the point is that optimisations come in many flavours. The > sum of the techniques used is very hard to predict as everyone > is saying but some basics can be used as an aid to stylesheet > coding style. When I write int i,j; j=0; for(i=0;i!=n;++i) { j=abs(0); } I expect that function abs is called n times. A clever compiler can analyse code of abs and conclude that it is a pure function, and factor it out of the loop; this is in no way a required or expected feature. On the other hand, if a template contains a variable definition that does depend on template's parameters, <xsl:template name="footer"> <xsl:variable name="doctitle" select="/book/descendant::title[1]"/> the programmer should expect that the computation takes place only once. Moreover, if it takes the form <xsl:template name="footer"> <xsl:param name="n"/> <xsl:variable name="doctitle" select="/book/descendant::title[position() = $n and starts-with(normalize-space(.),'Chapter')]"/> one should have the right to expect that for each n the computation is performed once, and if a template is called with the same value of 'n' repeatedly, it does not spend time on computing doctitle again. This is a feature of the language -- the language itself makes passing parameters and constructing temporary values syntactically difficult, but computational restrictions would allow to specify efficient algorithms without these features. A lot of complications brought by EXSLT and XSLT 2 could have been omitted if implementations were required to follow certain computational rules. For example, some languages rely on automatic memory re-use (garbage collection) or lazy evaluation of expressions. For such languages, not implementing these features would make expressing many algorithms simply impossible. The same holds for XSLT. Most extensions to XSLT 1.0 compensate for deficiencies of implementations which do not support efficient computation based on features of XSLT. And it is not because the implementations are bad, but because it is not required for conformance. Therefore, determining required optimizations (and 'optimization' is a wrong word -- computational rules) and requiring conformant implementations to follow them would keep the language simple and easy to use. Extending the language to bring features which are redundant and put the burden of reasoning about the features of XSLT data model on the programmer does the opposite. David Tolpin http://davidashen.net/ 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
|