I recently had a project where I needed to ingest large XML documents using C# so I was curious which XML reader technology would be the fastest. So I coded up a quick benchmark that would compare LINQ to XML, XmlDocument.Load, and XmlReader against each other.
The Test Data
I generated a very simple XML file before each run of a test. The id's were random and the number of "child" nodes varied based on the run. The following is an example of the test data I used.
<span class="kwrd"><</span><span class="html">root</span><span class="kwrd">></span>
<span class="kwrd"><</span><span class="html">child</span> <span class="attr">id</span><span class="kwrd">='123'</span><span class="kwrd">/></span>
<span class="kwrd"><</span><span class="html">child</span> <span class="attr">id</span><span class="kwrd">='234'</span><span class="kwrd">/></span>
...
<span class="kwrd"></</span><span class="html">root</span><span class="kwrd">></span>
The Test
As I said before I wanted to compare LINQ to XML, XmlDocument.Load, and XmlReader against each other. I ran each of these technologies using 1, 10, 100, 1000, 10,000, 100,000 "child" nodes. I also ran each against a XML document using UTF-8, ASCII, and UTF-32 encodings. Each iteration was run 100 times to reduce anomalies. In each of the tests I call the method "ProcessId" which simulates the processing of the "id" attribute.
XmlDocument.Load
I thought the code for XmlDocument.Load was the cleanest and easiest to understand, although I must admit I like XPath. XmlDocument does have some security concerns but that's another post. Here is the code I used to load and search the document:
<span class="kwrd">private</span> <span class="kwrd">static</span> <span class="kwrd">void</span> XmlDocumentReader(<span class="kwrd">string</span> fileName) {
XmlDocument doc = <span class="kwrd">new</span> XmlDocument();
doc.Load(fileName);
XmlNodeList nodes = doc.SelectNodes(<span class="str">"//child"</span>);
<span class="kwrd">if</span> (nodes == <span class="kwrd">null</span>) {
<span class="kwrd">throw</span> <span class="kwrd">new</span> ApplicationException(<span class="str">"invalid data"</span>);
}
<span class="kwrd">foreach</span> (XmlNode node <span class="kwrd">in</span> nodes) {
<span class="kwrd">string</span> id = node.Attributes[<span class="str">"id"</span>].Value;
ProcessId(id);
}
}
LINQ to XML
LINQ to XML was also very easy to read and understand code. I did find that even though LINQ to XML is supposed to use XmlReaders under the covers calling XDocument.Load does read the whole document into memory before returning. So if you are looking for data at the top of middle of a very large document this could be a concern. Here is the code I used to load and search the document:
<span class="kwrd">private</span> <span class="kwrd">static</span> <span class="kwrd">void</span> XDocumentReader(<span class="kwrd">string</span> fileName) {
XDocument doc = XDocument.Load(fileName);
<span class="kwrd">if</span> (doc == <span class="kwrd">null</span> | doc.Root == <span class="kwrd">null</span>) {
<span class="kwrd">throw</span> <span class="kwrd">new</span> ApplicationException(<span class="str">"invalid data"</span>);
}
<span class="kwrd">foreach</span> (XElement child <span class="kwrd">in</span> doc.Root.Elements(<span class="str">"child"</span>)) {
XAttribute attr = child.Attribute(<span class="str">"id"</span>);
<span class="kwrd">if</span> (attr == <span class="kwrd">null</span>) {
<span class="kwrd">throw</span> <span class="kwrd">new</span> ApplicationException(<span class="str">"invalid data"</span>);
}
<span class="kwrd">string</span> id = attr.Value;
ProcessId(id);
}
}
XmlReader
XmlReader, specifically XmlTextReader was the hardest to write and understand. With it's quirks of being a forward only reader you need to take what you need while you have it because you can't rewind.
<span class="kwrd">private</span> <span class="kwrd">static</span> <span class="kwrd">void</span> XmlReaderReader(<span class="kwrd">string</span> fileName) {
<span class="kwrd">using</span> (XmlReader reader = <span class="kwrd">new</span> XmlTextReader(fileName)) {
<span class="kwrd">while</span> (reader.Read()) {
<span class="kwrd">if</span> (reader.NodeType == XmlNodeType.Element) {
<span class="kwrd">if</span> (reader.Name == <span class="str">"child"</span>) {
reader.MoveToAttribute(<span class="str">"id"</span>);
<span class="kwrd">string</span> id = reader.Value;
ProcessId(id);
}
}
}
}
}
The Results
The following results are in milliseconds for each run. I took the total time to run and divided it by 100.
UTF8Encoding
| 1 | 10 | 100 | 1,000 | 10,000 | 100,000 |
|---|
| XmlDocument | 0.1567800 | 0.1713450 | 0.3888620 | 1.9816480 | 22.8049260 | 459.8570340 |
|---|
| XmlReader | 0.1467460 | 0.1439580 | 0.2300500 | 0.8534400 | 7.5771640 | 76.8635690 |
|---|
| LINQ to XML | 0.1499530 | 0.1500640 | 0.2778720 | 1.4616730 | 15.7719020 | 208.9360300 |
|---|
ASCIIEncoding
| 1 | 10 | 100 | 1,000 | 10,000 | 100,000 |
|---|
| XmlDocument | 0.1659350 | 0.1922080 | 0.3433140 | 1.9846330 | 22.5484690 | 482.8699720 |
|---|
| XmlReader | 0.1376840 | 0.1453730 | 0.2199810 | 0.8768260 | 7.9187380 | 77.7760560 |
|---|
| LINQ to XML | 0.1345900 | 0.1573340 | 0.2848420 | 1.4889930 | 15.1504500 | 214.9338990 |
|---|
UTF32Encoding
| 1 | 10 | 100 | 1,000 | 10,000 | 100,000 |
|---|
| XmlDocument | 0.1672370 | 0.1799780 | 0.4156250 | 2.7188370 | 30.6423960 | 543.4604540 |
|---|
| XmlReader | 0.1386820 | 0.1503870 | 0.2867400 | 1.4981070 | 14.4428430 | 152.7660780 |
|---|
| LINQ to XML | 0.1317060 | 0.1866610 | 0.5385940 | 2.3631290 | 21.4566290 | 274.3280280 |
|---|
Conclusion
XmlReader beats LINQ to XML in almost every run except for very small XML documents. What's interesting is how the numbers scale between the encodings. XmlReader is over twice as slow when reading UTF-32 documents verse UTF-8 or ASCII encoded XML, yet LINQ to XML and XmlDocument slowed down by a much smaller amount.
If you need speed when reading XML documents stick with XmlReader. If you need readability and maintainability of your code go with LINQ to SQL or XmlDocument.