Re: [xsl] performance of very very bad wtf-quality xslt

Subject: Re: [xsl] performance of very very bad wtf-quality xslt
From: bryan rasmussen <rasmussen.bryan@xxxxxxxxx>
Date: Fri, 30 Sep 2005 12:58:52 +0200
This is currently what I'm doing. ohhhh, it's painful.

On 9/30/05, James Fuller <jim.fuller@xxxxxxxxxxxxxx> wrote:
> 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
> * 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

Current Thread