Re: performance of very very bad wtf-quality xslt

bryan rasmussen wrote:

>The problem is that my employers decided to put it out on a web site
>as a wonderful example of translating between these formats. Well now
>the second worst xslt ever has come into my possession. It is somewhat
>better. I doubt that there is any nesting of for-each any lower than
>six levels. and there are some templates that have been defined. This
>one is to do the transformation back from format 2 to format 1.
>
>  
>
snip....

>That's great. One problem is we don't have a good test set of
>documents, some possible documents could be very big, I am worried
>about performance problems applying to the following areas:
>
>1. for-each as a whole
>2. nested for-each
>3. for-each over attributes, for example if one just wants to
>transform a commonly occuring set of attributes I can't see how the
>AST that comes out of an xslt could be optimized for doing that with
>for-eaches, whereas it would be relatively easy with transforms.
>4. performance hits on various processors for if statements and
>choose-when statements.
>5.Any other performance parameters that you can think of in this
>context (one obvious one is that these stylesheets are approximately
>8-10 times larger than they need to be.)
>

..oh well its surprisingly easy to refactor XSLT code in such
situations...I find it easier to convince clients to refactor by;

* stating that its easy to crack apart this kind of mess by exporting
code blocks into seperate templates and via multiple (and seperate XSLT)
pass XSLT

* instrumenting the code (baselining the mess u have now) to absolutely
know performance gains with each refactoring

* you can enforce change in the XSLT by first looking at the data
structure and changing that

* the same technique of enforcing change works when changing schemas as well

* instrumenting the code with unit tests is useful in understanding the
problem as well as ensuring robustness throughout maintenance

* you might also run this code through various XSLT to see if there are
any issues

gl, Jim Fuller