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