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 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
Current Thread |
---|
|
<- Previous | Index | Next -> |
---|---|---|
Re: [xsl] how to estimate speed of , J.Pietschmann | Thread | RE: [xsl] how to estimate speed of , Michael Kay |
Re: [xsl] how to estimate speed of , David Carlisle | Date | Re: [xsl] how to estimate speed of , David Tolpin |
Month |