Subject: Re: [xsl] performance of very very bad wtf-quality xslt From: James Fuller <jim.fuller@xxxxxxxxxxxxxx> Date: Fri, 30 Sep 2005 12:42:54 +0200 |
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
Current Thread |
---|
|
<- Previous | Index | Next -> |
---|---|---|
RE: [xsl] performance of very very , Michael Kay | Thread | Re: [xsl] performance of very very , bryan rasmussen |
Re: [xsl] Retaining Entity refrence, David Carlisle | Date | Re: [xsl] performance of very very , bryan rasmussen |
Month |