XML transformation

[Guest]

In my application I am transforming the XML based on XSL. Then I've to show
the transformed content in the browser. (.net -C#)
For that I am dumping the transformed content in a file, then i am reading
the content from that file and showing in the browser.

Is there any way I can avoid writing in the file.

 

[Marc Gravell]

Is the transform at the client or the web-server?

If the web-server, then you should be able to pass the response-stream
(or a writer in a suitable encoding) directly to the
XslCompiledTransform, so it can write directly to the response stream.

If the client, then if you are happy to use IEs choice of XSL you could
use the trick of embedding the transform into the xml and let IE worry
about it. Otherwise you could perhaps transform into to a StringWriter,
and then write the .ToString() into the browser's HTML.

Any use?

Marc

 

[Guest]

Well the application is a stand-alone tyep. It will show the transformed
content in the browser embedded in the window-Form.
this is thing which I'm doing:

XPathDocument myXPathDocument = new
XPathDocument(XMLfileName);
XslCompiledTransform myXslTransform = new
XslCompiledTransform();
writer = new XmlTextWriter(outputFileName, null);
myXslTransform.Load(xslFileName);
myXslTransform.Transform(myXPathDocument,null, writer);
writer.Close();
stream = new StreamReader(outputFileName);
string output = stream.ReadToEnd().ToString();


the problem is that it takes around 5 seconds in the very first time to show
the content after that it does the same activity within 1 second or so.

so i've to reduce this time thing. So What i see that since IO operation are
time consuming operation and if we are able to remove file writing and
reading we can save some time.
So any idea in that side??

 

[Marc Gravell]

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

 

[ssamuel]

Try this:

// ensure:
using System.Text;
using System.IO;

// This is your code:
XPathDocument myXPathDocument = new XPathDocument(XMLfileName);
XslCompiledTransform myXslTransform = new XslCompiledTransform();
// Prepare an output stream based on a System.Text.StringBuilder():
StringBuilder sbResult = new StringBuilder();
StringWriter sResult = new StringWriter(sbResult);
XmlTextWriter sXML = new XmlTextWriter(sResult);
// Load the XSL, your code:
myXslTransform.Load(xslFileName);
// Perform transform, your code modified to use new stream:
myXslTransform.Transform(myXPathDocument,null, sXML);
// Make sure the stream's written everything to the underlying buffer:
sXML.Flush();
// Retrieve string:
string output = sbResult.ToString();


If you have a string input instead of a file (i.e. -- if you're writing
your string to a file because you don't know how to create an
XPathDocument based on a stream or a string), you can do something
similar with a StreamReader or StringReader/XmlTextReader.

If you're still having performance issues, you need to perform the
stems that Marc suggested, like looking at: 1) the size of the XML, 2)
the size of the XSL, 3) the quality of the XSL code. You should be able
to transform a 1 MB XML with an XSL file around 5k that's well written
without any noticeable delay.


Stephan