tags:

views:

871

answers:

5
+2  Q: 

Linq to XML vs DOM

Hi,

In one of the applications we are developing we do lot of XML processing. Currently we use DOM and XPath for most of the processing and we are not much happy with the performance.

At the moment we are considering of moving XML processing logic to LINQ and our initial investigations suggest LINQ performance is much better than DOM.

Before making these changes I would like to know how others feel about this. Is using LINQ a better option? Any disavantages etc...

Thanks, Shamika

+1  A: 

My take on it is that LINQ -> XML is leaps and bounds easier to use than DOM. It's more intuitive to me and much easier to read IMO.

Gromer
+1  A: 

Take a look at this question: http://stackoverflow.com/questions/182976

Jonathan Parker
+2  A: 

I'm not sure you would notice a very large performance improvement using LINQ2XML instead of DOM/XPath. For both DOM and LINQ2XML the document that you iterate over, is represented as an in-memory tree.

If performance really is an issue and you have rather large XML documents, you could take a look at the rudimentary XML streaming support that is implemented in the framework (via XStreamingElement). Also check this Microsoft XML team blog entry.

Ronald Wildenberg
A: 

Using DOM (i.e. System.Xml.XmlDocument) is likely to be slower, because of the rich navigation support (all those references start to add up), and this overhead will become more significant as the number of nodes increases.

Simpler object models (System.Xml.Linq.XDocument and System.Xml.XPath.XPathDocument) don't habe such complex structures, but allow navigation by other means. This might add to CPU overhead but should save memory.

In the end you need to profile (time and space) in your case, and also consider how much real (user perceived) difference it makes.

But, for ultimate performance don't load the whole document into memory at all: use System.Xml.XmlReader and System.Xml.XmlWriter and do everything in a stream. Of course this adds development cost.

.NET has a rich (maybe too rich) set of XML APIs, which is best (or at least, least worst) for you can only be determined by you making the trade-offs which are best for you.

Personally I would avoid XmlDocument and use either XPathDocument (especially to read, and query with XPath) or XElement (especially to create) where XmlReader/XmlWriter does not give enough of a performance boost to justify.

Richard
A: 

Hi All,

Thank you very much for your answers. I did some performance tests and as expected XmlReader out performed both XmlDocument and LINQ. Please note that this is only for XML reading.

Also if you need the ease of use of LINQ you can implement LINQ XML processing by using some features of the XmlReader and can get much better performance than XmlDocument. Please refer to "rwwilden" comments for more information.

Thanks.