xsl-list
[Top] [All Lists]

Re: how to estimate speed of a transformation

2003-12-11 06:16:58
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
optimization. 

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
computed.

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
  cases. 

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:  http://www.mulberrytech.com/xsl/xsl-list