[XSL-LIST Mailing List Archive Home] [By Thread] [By Date]

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

---

---

On Thursday 11 December 2003 07:28, David Tolpin wrote:
>
> 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.
>

In principle I would agree, although without very much precedent 
for such in other languages I think it may be a hard sell. 
Sounds like you might have some good insight into what might be 
good computational rules. Tail recursion is such an obvious one 
but the variable example is a little more involved.

It appears that the choices are:-
0 times - Allowed only if variable is not used 
n times - Once for each value of 'n'
x times - Once for each call of the template (probably the 
default)

However there is also potential performance gain from using the 
variable only as a specification and not the basis of execution. 
So a processor may choose to execute the equivalent of:-

<xsl:template name="footer">
  <xsl:param name="n"/>
  <xsl:variable name="titles" select="/book/descendant::title"/>
  <xsl:variable name="doctitle" select="$titles[position() = $n 
and starts-with(normalize-space(.),'Chapter')]"/>

Clearly here the titles variable could then be evaluated only 
once and the doctitle variable has the same options as above. I 
have worked in this area where the goal is performance 
optimisation and found it very difficult to locate good 
heuristics for strategy selection, although we occasionally find 
some real big gains for this type of work.

I suspect you are more concerned with having known behaviour 
rather then necessarily best performing behaviour. I think there 
is a case for that as long as it does not overly restrict a 
processors ability to select its own best execution strategy. I 
would probably consider variable evaluation strategy as an 
example of such a case, i.e. where the benefit of allowing 
performance tweaking outways the benefit of knowing when/how 
things are evaluated.

Kev.


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

---