LINQ to XML - Performance - Speed

[CodeRazor]

Hi, Can anyone tell me how the performance compares between working with xml
documents in the normal way (i.e. with xpath and the System.Xml) and LINQ.

Is it any quicker or slower?

Are there are distinct benefits to the user (and not just advantages for the
coder) to working with LINQ?

The work i will be doing is creating an xml document out of segments from
other xml documents, transforming the document (XSL) and then
retrieving/amending/appending data to the document. Currentlly xml
transformations in .net 2.0 are very slow and performance takes a real hit
with complex transforms. Is it quicker in 3.5?

I can only seem to find advantages for the coder eg. it's easier and quicker
to code xml queries with 3.5, what about the user benefits?

thanks.

 

[Bill McCarthy]

Hi,

XElement is lighter than XMLDocument etc. But this won't change anything if
you are reliant on XSL. With XLINQ you can pretty much abandon XSL and do
the same in code using LINQ over the XDocument or XElements.

 

[CodeRazor]

Thanks bill.

Question 1) Would doing an "xsl transform" using XDocument and XElements be
quicker than doing a transform in the old way (i.e. using xsl)? If so, what
kind of difference is there?

I have some heavy transforms i need to do (currently these exist as long and
complex sylesheets) which inevitably mean the user has to wait around for
around 4-5 seconds for the content output to load.

Question 2) Can tranforms done in LINQ cope with long and complex
transformations? The examples i've seen have always only needed to do very
small transformations to maybe a couple nodes.

Question 3) When you say that XElement is lighter, do you mean that in pages
where there is loads of processing to be done to my xml, it will be quicker
with XElement and LINQ rather than with the old style XmlDocument and XPath.

thanks!

 

[Bill McCarthy]

Thanks bill.

Question 1) Would doing an "xsl transform" using XDocument and XElements
be
quicker than doing a transform in the old way (i.e. using xsl)? If so,
what
kind of difference is there?

I have some heavy transforms i need to do (currently these exist as long
and
complex sylesheets) which inevitably mean the user has to wait around for
around 4-5 seconds for the content output to load.

xsl when compiled can be pretty efficient, but if it is not precompiled it
can be expensive and relatively slow. XElement is light weight in
construction, so it's manipulation is akin to object manipulation.

The question is do you want to re-write all the XSL ? Perhaps the best I
could suggest would be to look at the heaviest part of the XSL and time that
part with an equivalent in XLINQ.

Question 2) Can tranforms done in LINQ cope with long and complex
transformations? The examples i've seen have always only needed to do very
small transformations to maybe a couple nodes.

They can. There are some issues where you may find yourself having to write
a helper method or extension, but the basics of querying over the xml using
conditional statements over any axes is there. The nice thing about LINQ is
query are compositional, and likewise you can also break the creation
ofparts and child parts apart.

Question 3) When you say that XElement is lighter, do you mean that in
pages
where there is loads of processing to be done to my xml, it will be
quicker
with XElement and LINQ rather than with the old style XmlDocument and
XPath.

I'd expect it to be, but XPath may have optimizations also when compiled
that may change that. Generally I would say yes, but as soon as I do,
someone will provide an exception to that rule

 

[CodeRazor]

thanks bill - you're responses have been really concise and helpful!

What you have to say about recompiling the xsl stylesheets sounds
interesting I've not heard much about that. Can you give me a summary of what
that would involve in .net?


thanks!

 

[Nicholas Paldino [.NET/C# MVP]]

Reading this thread, I get the feeling that you are using the
XslTransform class (which is obsolete as of 2.0 I believe) and not the
XslCompiledTransform class. What Bill is referring to here is that class
(XslCompiledTransform). You should see a performance gain compared to the
XslTransform class when using it.

 

[Bill McCarthy]

Yep. And in 2008 you can also compile the style sheet using xsltc.exe and
pass that assembly in rather than have the initial parse occur at runtime.

Reading this thread, I get the feeling that you are using the
XslTransform class (which is obsolete as of 2.0 I believe) and not the
XslCompiledTransform class. What Bill is referring to here is that class
(XslCompiledTransform). You should see a performance gain compared to the
XslTransform class when using it.


--
- Nicholas Paldino [.NET/C# MVP]
- (e-mail address removed)

thanks bill - you're responses have been really concise and helpful!

What you have to say about recompiling the xsl stylesheets sounds
interesting I've not heard much about that. Can you give me a summary of
what
that would involve in .net?


thanks!

 

[CodeRazor]

thanks to you both. That has really helped.