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 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 , James Fuller | Thread | Re: [xsl] performance of very very , bryan rasmussen |
Re: [xsl] performance of very very , James Fuller | Date | Re: [xsl] performance of very very , bryan rasmussen |
Month |