Re: [xsl] how to estimate speed of a transformation

[David Tolpin <dvd@xxxxxxxxxxxxxx>]

[ 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