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
>