Reply to: XSL tranforms in .NET

[mcquiggd]

Bah! Why didn't they employ Polish chappies like what we do like....

[DimPrawn]

The problem is all this dodgy code written by Russians:

Authors: Sergey Dubinets, Anton Lapounov

[mcquiggd]

Alexei....

Check out this....

http://blogs.msdn.com/xmlteam/articl...Transform.aspx

Although marked as 'unfinished' it does seem to back yup your observation ... executing the transform is performed using an XmlReader that traverses the whole document.


"Performing the Transformation
Once the stylesheet is fully loaded, XslCompiledTransform can transform the input document. Transformation of the input document to output involves the following steps:

Parsing the input document and building an in-memory XML tree representation for it.
Transforming the input XML tree to the output tree.
Serialization of the output tree.
To load the cache, XslCompiledTransform uses XmlReader to read the input document. At this time, XslCompiledTransform applies whitespace stripping rules.
"

[HankWangford]

mvp.xml

4.8 MB .NET distribution?

No, a hybrid solution was proposed - query object using XPath and then pass that XML to XSL template, it better fking work!

also check out the mvp xml project, they like wraping and increasing the performance of the frameworks xml/xsl methods http://sourceforge.net/projects/mvp-xml/

[AtW]

4.8 MB .NET distribution?

No, a hybrid solution was proposed - query object using XPath and then pass that XML to XSL template, it better fking work!

[DimPrawn]

Have a look see if this is any better

http://saxon.sourceforge.net/

[AtW]

Xsl transform functions is clearly a badly written piece of code, strange as it seems to be written by Russians ...

Shimano - chew your gum dude...

[Shimano105]

I guess your code is just tulip then AtW.

If .NET hurts, you ain't doing it right.

[DimPrawn]

I guess your code is just tulip then AtW.

If .NET hurts, you ain't doing it right.

[AtW]

As you can see from code above I use XPathNavigateable object, which should ensure tranformations are fast. XPath queries directly on that object work fast and nice. However giving it to Transform function of XSL is slow even when XSL document is empty - ie no queries there at all, none zero zilch. I can see from debugger that the damn thing walks whole tree of the XPathNavigeable object even though nobody asked it to do it - I can see it in debugger that they do it ffs. What's worse is that the damn thing adds to transformed results some junk that should not be there.

[Fleetwood]

Oi!

Put this in technical Webby,FFS!
The general forum is reserved for mindless tosh, not this IT-related geek-speak.

[AtW]

I use FX 2.0.

I have got a custom object that implements XPathNavigator - this allows to run XPath queries and those work just fine, no problems there.

Then I thought to use XSL to run those XPath statements, here is how I do it:

       public string ExecXSLT(string sFileName,XsltArgumentList oList)
        {
            XslCompiledTransform oXsl=new XslCompiledTransform();

              // loads XSL template
            oXsl.Load(sFileName); 

            return ExecXSLT(oXsl,oList);
        }

    public string ExecXSLT(XslCompiledTransform oXsl,XsltArgumentList oList)
        {
            StringBuilder oSB=new StringBuilder();

            XmlWriterSettings oWS=new XmlWriterSettings();

            oWS.Indent=true;
            oWS.NewLineHandling=NewLineHandling.None;
            oWS.Encoding=Encoding.UTF8;
            oWS.OmitXmlDeclaration=false;
            oWS.ConformanceLevel=ConformanceLevel.Auto;

            XmlWriter oWriter=XmlWriter.Create(oSB,oWS);
      
            // Xnav is XPathNavigator object that controls actual data document that should be dealt with by XSL
            oXsl.Transform(Xnav,oList,oWriter);
           
            return oSB.ToString();
        }

The POS XSL implementation walks whole XPathNavigator object even is XSL template is empty! This is bad enough to disqualify it because whole purpose of XPathNavigator is to avoid performance hit of having to deal with whole document - note that separate XPath statements run directly work just fine, they dont walk whole object, only parts necessary.

[HankWangford]

I've got running test here that made me certain it happens - I pass XPathNavigator object to it, if I run XPath directly on that object then it only touches bits that have to be touched, when I put same XPath into XSL document I can see that whole object is walked, in fact if I have empty (!) XSL template the fking thing still walks the whole object. How do I know? Because I've got XPathNavigator over normal live .NET object and can see that its being walked over.

To add insult to injury it appears that XSL POS adds some junk into output that should not be there - its junk and some searches on the Net seems to confirm that.

Seems i didnt dig deep enough into the wrath of the internal methods. From the horses mouth an explanation as to what goes on under the hood. Good article
Compiled XSLT explained

[DimPrawn]

This should be posted in the technical forums.

What are you using, an XmlDocument or XPathDocument or XmlDataDocument?

How are your XPath queries formulated? Do by their nature have to traverse the whole document to find the required node(s)?

Please read http://support.microsoft.com/kb/325689/EN-US/

PS V1.1 of the framework has a lot of issues processing XSLT on large XML documents. I believe V2.0 is much better in this respect.

[AtW]

I've got running test here that made me certain it happens - I pass XPathNavigator object to it, if I run XPath directly on that object then it only touches bits that have to be touched, when I put same XPath into XSL document I can see that whole object is walked, in fact if I have empty (!) XSL template the fking thing still walks the whole object. How do I know? Because I've got XPathNavigator over normal live .NET object and can see that its being walked over.

To add insult to injury it appears that XSL POS adds some junk into output that should not be there - its junk and some searches on the Net seems to confirm that.