Hi guys,

Thanks for the feedback.

In the application, I am only loading the XSL once at the start and
then I transform as many times as is needed for the number of XML
documents that need processing. In this case 350 XML documents. So
there is absolutely only 1 XSL document load which is then used 350
times in a transform.

After the application has finished processing it then exits.

Note that this is a standalone console app it isn't used as a web
script etc. It does some batch processing and then quits.

What I found when I ran it was that the first time I ran the
application it took longer to load the XSL document using both the new
and the old code but on subsequent runs it then took the same amount of
time which was shorter to load it afterwards. Hence the information was
being cached and reused on subsequent executions.

Thus when I ran each version of the application 50 times, the 1st time
it was run I got the first load times [233ms and 71ms] and then the
other 49 times I got more or less the same but quicker loading times of
11ms and 30ms.

Oleg, The pertinent bits of my source code are displayed in my first
post, and the classes are really too big to throw into here.
Realistically, all I've done is compare the old with the new versions
of XSL transformation using an existing class that does a *lot* of
other processing.

In real terms the bottleneck in this application is the time required
to process the XML which can be up to 1 or 2 seconds depending on the
complexity of the created documents. However that is equal from one run
to the next so if I'm introducing a bottleneck using the compiled
Transformation class of an extra 100ms for the transformation then that
starts to cause problems down the line when I'm transforming several
thousand XML documents in one go...

If any of you guys have any ideas for optimisation I'll gladly hear
them and I'm willing to be swayed - to be honest I'd prefer to use
XslCompiledTransform because I get extra XSL options that you don't get
with the XslTransform class and that would be good, but the time
penalty is still too high to use this in production at the moment.

Cheers
Andrew




The
Kevin Spencer wrote:
> You should only be loading the XSL one time, as per my original reply. Here
> is a repost of the example I gave you:
>
> XmlReaderSettings readerSettings = new XmlReaderSettings();
> readerSettings.ProhibitDtd = false;
> XsltSettings transformSettings = new XsltSettings(false, true);
> _HtmlTransform = new XslCompiledTransform();
> TextReader reader = new StringReader(Properties.Resources.HtmlTransform);
> XmlReader htmlReader = XmlReader.Create(reader, readerSettings);
> _HtmlTransform.Load(htmlReader, transformSettings, null);
> reader.Close();
>
> --
> HTH,
>
> Kevin Spencer
> Microsoft MVP
> Short Order Coder
> http://unclechutney.blogspot.com
>
> The devil is in the yada yada yada
>
>
> "AndrewF" <andrew@t...> wrote in message
> news:1162461523.419153.130430@e......
> > Hi all,
> >
> > First up, thanks Elena for the heads up on the XML Reader class - to be
> > honest I wasn't expecting there to be a huge problem with it but
> > couldn't see such a massive performance drop being based solely on the
> > XSLCompiledTransform class.
> >
> > Also thanks for noting that I can in fact pass in the original
> > XMLDocument object rather than casting it to a text reader first. I've
> > done that now as a point of optimisation and it will make it easier to
> > do a direct comparison on execution times.
> >
> > So here's what I did - I threw a stopwatch timer around the specific
> > segments of code so I could see how long it takes to do things. I put
> > it around the XSL load code at the start, the actualy Transform()
> > method itself and also around the processing code I to produce the XML
> > just for point of comparison so I can make sure the code was equal in
> > terms of general performance.
> >
> > I ran this 50 times for each form of the code so I could get the
> > benefits of any caching. The machine was also rebooted when switching
> > from the old code to the new code so it was running "fresh" each time.
> >
> > The test case was processing 350 XML files using a single XSL template
> > which comprised 8 individual "included" files. The XSL is quite
> > complext with a lot of control statements in it to generate branching
> > and heavy template re-use. IE it is a real-life example of the XSL
> > required to produce the templates for a medium sized web site.
> >
> > Old code first:
> >
> > First load of the XSL template: 233ms
> > Subsequent loads of XSL template: 11ms average
> >
> > XML Processing Time: 18ms
> >
> > Transform() time: 5ms average
> >
> > New code:
> >
> > First load of the XSL template: 71ms
> > Subsequent loads of XSL template: 30ms average
> >
> > XML Processing Time: 18ms
> >
> > Transform() time: 105ms average
> >
> > This is a *direct* comparison of the XslCompiledTransform class to the
> > XslTransform class in a production environment using real-life code. As
> > you can see the averages of the XML processing time are equal and
> > therefore the binary isn't different enough to cause execution time
> > changes from the old to the new code.
> >
> > What is interesting is that the first load is substantially quicker
> > using CompiledTransform as well though subsequent ones aren't so quick.
> > Note that this test didn't compare the "load times" of the actual
> > XSLDOC.Load() method, rather it test the "process times" of the load
> > process. This is because in XSL Tranform you can just pass a file name
> > to the document and it will open it. In the compiled transform you have
> > to do other work as indicated in my first post *in order to get the
> > same behaviour* in terms of white space etc.
> >
> > The direct comparison between the Transforms though is staggering.
> > Whatis even more interesting is that I initially ran this with my
> > "casting" code taking the XML document and turning it into an
> > XMLTextReader and this didn't really alter the performance of the new
> > code. There was about a millisecond of difference in real terms as far
> > as performance goes.
> >
> > So the next question is why is this the case? Has MS not tested this on
> > really difficult XSL? Are there optimisations we can do with the XSL.
> > In all seriousness the XSL that I saw used on Anton's blog with the
> > chess stuff isn't particularly difficult code, it is just executing
> > lots of times in loops and maybe this is where we get some performance
> > increase...
> >
> > Any ideas guys?
> >
> > Cheers
> > AndrewF
> >