Devlico.Us
CodeBetter.Com
RSS 2.0 via Feedburner
           Do you Twitter? Follow us @devlicious

Derik Whittaker

Thoughts on Software Development, .Net, OOP, Design Patterns and all things cool



XLinq'n in the new world - Speed comparison with Xml/XPath

Originally this series was meant to be titled 'Any thing you can do I can do better', but to be honest after writing the Xml/XPath examples I realized the XLinq is really no better per say than Xml/XPath.  However, what XLinq does bring to the table that Xml/XPath does not:

  • Does not need to use the XPath query syntax
  • Reads like English (mostly) when creating queries
  • Lower barrier to entry for someone new to Xml (my opinion)

For Part 1 of this series check here
For Part 2 of this series check here
For Part 3 of this series check here

In Part 4 of this little mini-series we will examine the speed differences between XLinq and Xml/XPath.

Before I get started I will show you a sample of the XML document I am using.  The sample document I am using today is 5.25mb in size.

<?xml version='1.0'?>
<root>
  <system>
    <list>
      <subscribers>
        <subscriber Type="Random">
          <id>63425813</id>
          <Email__Address>FakeAddress@comcast.net</Email__Address>
          <EmailType>HTML</EmailType>
          <Status>InActive</Status>
          <First__Name>RAY</First__Name>
          <Last__Name>Bob</Last__Name>
          <PIN__Code>NaN</PIN__Code>
          <PIPIN>33232</PIPIN>
          <UID>418444</UID>
          <ProgNum>0</ProgNum>
          <Title />
          <Username />
          <Password />
        </subscriber>
      </subscribers>
    </list>
    <list>
      <subscribers>
          <subscriber>
          <id>1271728821</id>
          <Email__Address>FakeAddress@yahoo.com</Email__Address>
          <EmailType>HTML</EmailType>
          <Status>InActive</Status>
          <First__Name>JOHN</First__Name>
          <Last__Name>Foo</Last__Name>
          <PIN__Code>NaN</PIN__Code>
          <PIPIN>1254512</PIPIN>
          <UID>1033488</UID>
          <ProgNum />
          <Title />
          <Username />
          <Password />
        </subscriber>
      </subscribers>
    </list>
  </system>
</root>

Example 1 - Loading a XML document from Resource Stream

There is no real code to show here, but I do have some speed numbers to chat about.  I ran my test 2 times. The first time I loaded into a XLinq object first then into an XmlDocument object and for the second run, I swapped the order.

As it turns out the first document to load each time is slower, but you can get a look at the speed difference by looking at the delta between each load time.

Load Time

XmlDocument 515.00 327.72 187.27 (Delta)
XLinq 358.94 546.2135 187.27 (Delta)

By looking at the above, there is no real speed difference, which I expected. (Time above is in milliseconds)

Example 2 - Finding a Unique value in the Xml Document

For this example I decided to try to find a single node inside my larger xml file.  In order to try to get good sample I ran each test 5 times and the times below are the average of all those runs

Run time (5 run avg)

XLinq 44.62
Xml/XPath 125.65

I have to say that I was kinda surprised by the results.  I figured that the Xml/XPath way would be a little faster, but turns out it is 3 times slower. (Time above is in milliseconds). ** NOTE *** The times above do NOT include the time needed to load the XML document into the correct object model.

From the information in this mini-series i would conclude that if you need to do any type of XML reading/manipulation/creation I would make the jump over to using XLinq as your preferred way of doing so.

Till next time,



Comments

JaredPar said:

It would be great if you could post a small sample app that detailed how you performance tested the scenarios.  That would give us a lot more context into the performance data.  

# May 14, 2008 5:19 PM

stevef said:

also are you using the XPathDocument or the sluggish XMLDocument?

# May 14, 2008 8:32 PM

Reflective Perspective - Chris Alcock » The Morning Brew #94 said:

Pingback from  Reflective Perspective - Chris Alcock  &raquo; The Morning Brew #94

# May 15, 2008 3:12 AM

Xml processing performance « Noocyte’s Weblog said:

Pingback from  Xml processing performance &laquo; Noocyte&#8217;s Weblog

# May 15, 2008 4:13 AM

Dew Drop - May 15, 2008 | Alvin Ashcraft's Morning Dew said:

Pingback from  Dew Drop - May 15, 2008 | Alvin Ashcraft's Morning Dew

# May 15, 2008 8:39 AM

Sam Gentile said:

.NET/Visual Studio 2008 How to Download all of Visual Studio 2008 SP1 The Release of Visual Studio 2008

# May 16, 2008 7:31 AM

Craig said:

Hi. Firstly, thanks for a series of informative articles. Just the stuff I've been looking for when I started out re-writing a project that dealt with xml from a 3rd party.

I also looked at performance as one of the factors for choosing whether I'd go with XDoc/Xpath or Xlinq. My timed results were a little different though. I used the StopWatch class to measure 2 different implementations. I've encapsulated the implementations into 2 different classes and ran them (isolated) one by one from Main() in a console app. I also read the xml document into memory using GetManifestResourceStream().

The most perfomant under my conditions was the following:

XmlDocument doc = new XmlDocument();

doc.Load(fileStream);

The least performant was:

Stream s = GetManifestResourceStream()

StreamReader r = new StreamReader(s)

xElement = XElement.Load(r);

Combining the two approaches resulted in a bigger performance hit for me. Example:

XmlDocument doc = new XmlDocument();

doc.Load(fileStream);

xElem = XElement.Parse(doc.OuterXxml)

The approach I settled on however was using the XMLReader which came in at second most performant after the XmlDocument Xpath approach for my particular situation.

Hope this helps

Craig

# November 13, 2008 12:12 PM

Leave a Comment

(required)  
(optional)
(required)  

Enter the numbers above:
Add

About Derik Whittaker

Derik is a .Net Developer/Architect specializing in WinForms working out the northern suburbs of Chicago. He is also believer and advocate for Agile development including SCRUM, TDD, CI, etc.

When Derik is not writing code he can be found spending time with his wife and young son, climbing on his bouldering wall, watching sports (mostly baseball), and generally vegging out. Check out Devlicio.us!

Our Sponsors

Red-Gate!