I heard that LINQ to XML has some performance issues and some of my friends recommended me not to use it in my app. I couldn't find anything relevant on MSDN and I do not want to rely on "some internet blog". Does anyone know of a official point of view on this issue or some trustworthy source?
-
Comparison of XPath and LINQ to XML: http://msdn.microsoft.com/en-us/library/bb675156.aspx – Kris Ivanov Feb 06 '11 at 03:18
-
Related: http://stackoverflow.com/questions/14000846/xdocument-performance – nawfal Aug 20 '15 at 07:45
3 Answers
Using LINQ to XML will read the entire file into memory.
If you're reading an enormous XML file (hundreds of megabytes), this is a problem.
Instead, you can use a raw XmlReader, which provides a forward-only view of an XML file and will not read the entire file at once.
If you're dealing with normal-sized XML files, LINQ to XML will be fine.
LINQ to XML is several orders of magnitude easier to use than XmlReader.
You should only use XmlReader if you know that you'll be dealing with 200MB XML files, or if you've measured your performance and proved that the XDocument
constructor is being too slow.

- 868,454
- 176
- 1,908
- 1,964
-
8Microsoft does provide examples on how to stream input/output of an xml file using Linq to Xml so that you don't end up loading the entire file into memory only small chunks of it: http://msdn.microsoft.com/en-us/library/system.xml.linq.xstreamingelement.aspx#Y1392 – Michael Aug 14 '11 at 02:05
Just google linq vs xmlreader
you will have it.
The top result, http://www.nearinfinity.com/blogs/joe_ferner/performance_linq_to_sql_vs.html, leads to a conclusion that it's slower compare to xmlreader (of course, since linq2Xml is built on top of xmlreader), but IMHO it is far better than acceptable, as you gain the flexibility and easier to read/code.

- 27,357
- 8
- 59
- 64