Personally, I doubt that disk IO is the problem, unless you are writing
over the network.
5 seconds in the very first time to show
the content after that it does the same activity within 1 second or so
To clarify; are you re-running the code you posted when you do this? Or
are you re-displaying the existing (html) file? This 5 seconds could be
a number of things:
* "Fusion" loading the necessary assemblies (look to see what
assemblies are loading /when [in the output window of VS]); you could
try and force them load earlier to stop this looking slow
* Compiling the transform; although I'm not entirely sure about this
because from your code you don't actually seem to hold onto the
transform... so not entirely sure why you would bother compiling it ;-p
Generally I would expect this single XslCompiledTransform to be re-used
in successive calls
* Applying the transform; it isn't clear whether you are re-running it
each time; if not, it could just be a poorly written transform. The
typical example is grouping data; if you use axes such as ancestor:: or
preceeding-sibling:: to group data, you will get poor performance;
Munchean grouping is the way to do this...
Have you tried swapping the XmlTextWriter for a StringWriter? I suspect
this would be a very simple test, and would rule out the IO. You can
probably use the following overload, with arguments=null, since
StringWriter is a TextWriter. Note this /probably/ (haven't tested)
also avoids the runtime having to encode [writing] / decode [reading]
to / from bytes which you would have with a MemoryStream... as you
simply call .ToString() to get the HTML and set this (as a string) into
the browser control. Hopefully the HTML isn't insanely big.
Transform(System.Xml.XPath.IXPathNavigable input,
System.Xml.Xsl.XsltArgumentList arguments, System.IO.TextWriter
results)
But again, I strongly suspect that IO isn't the issue, unless you are
dealing with very large xml sets, in which case I would *actively
recommend* using the (local) file-system as the buffer, as it avoids
filling up system memory and having to keep block-copying the arrays as
it gets better (which is what would happen behind the scenes with a
MemoryStream).
Do you happen to have a short example (with the necessary xml and xslt)
that demonstrates this bottleneck? They may be a bit long for ideal
usenet usage, but if you e-mail them or post them somewhere I could
have a look-see...
Marc