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

Subject: Re: [xsl] how to estimate speed of a transformation
From: David Tolpin <dvd@xxxxxxxxxxxxxx>
Date: Thu, 11 Dec 2003 17:16:58 +0400 (AMT)
> > 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.
> The C/C++ and in particular the FORTRAN people did quite well without
> any explicit guarantees about what the compiler will optimize. Although
> everybody takes well-known techniques like constant folding, dead code
> elimination, loop strength reduction, loop unrolling, jump optimization
> and others for granted.

Most C/C++/FORTRAN optimizations do not change computational complexity due to nature
of these languages. Besides, most compiler optimizations optimize code
generated by compilers, not written by programmers. That is, constant folding
takes place in most cases when the compiler generates a constant expression
and then folds it, not when a human does. The same is about loop strength
reduction and dead code elimination. Programmers still have to develop optimal
algorithms and estimate computational complexity. Even with the most optimizing
compiler, execution speed seldomly doubles. I would be glad to see a prorgam in C/C++/FORTRAN/
which does something useful and which computational complexity depends on compiler's

While it is common with XSLT.

One cannot program in XSLT in the same way as he/she does in C/C++ or FORTRAN
since it has no control other the way memory is allocated or expressions are

> I can see why a lispisch/functional programming language requires the
> run time environment to provide tail recursion elimination, firstly
> because it's a reasonably simple and well established technology, and
> because it encourages using recursive functions instead of writing
> loops.

Because there is no way to write a loop in XSLT.

> I don't see what other optimizations should be guaranteed, mainly
> because stuff like handling lazy evaluation or chaching is *not* yet
> well established in the sense that the algorithms providing the
> optimizations guarantee that they always provide an advantage instead
> of proving detrimental even in quite common cases. You don't want to
> require a technique which is likely to slow down at least every tenth
> program, according to the current level of wisdom.

I am not asking for anything which is not here. Of four implementations
which are available to me (SAXON 6.5.3, jd.xslt 1.5.5, the last version of XT
released by J.Clark and a probably outdated version of xsltproc) 

- none handles indirect tail-recursion. It is good news, since I know that indirect
  tail recursion should be avoided in all cases when its  length is determined by
  the length of the data.
- at least two, but definitely not all, handle direct tail-recursion  adequately. 
  This news are not so good, since a stylesheet
  that appears to be efficient when developed with one implementation, will become slow
  and memory-hungry with another one.
- three memoize 'select' results. This is basically a good thing since it shows the trend.
  I hope that in the future a good implementation of XSLT will do that.
- two consistently exhibit constant access time by position() in all cases, + one in simple

What I am asking for is for rules I can follow to benefit from techniques already
available in good implementations; why should this knowledge be obtained empirically
or through reverse-engineering? I am good at reading others' source code -- I've learned
a lot. 

Is it normal that to use XSLT with consistent results one should read source code
in Java or C?

David Tolpin

 XSL-List info and archive:

Current Thread