9

I was wondering if there are any performance differences when using simple queries as:

var x = document.XPathSelectElement("actors/actor")

vs

var x = document.Descendants("actors").Descendants("actor")
Mattias
  • 684
  • 3
  • 7
  • 16
  • 2
    Side note: answers to this question ignore http://stackoverflow.com/questions/3705020/what-is-the-difference-between-linq-to-xml-descendants-and-elements - second query will return nodes like "/foo/actors/random_nodes/actor" unlike first one which only returns "actor" that is immediate child of "actors". – Alexei Levenkov Sep 11 '15 at 18:57

4 Answers4

9

Note that this

var x = document.Elements("actors").Elements("actor").FirstOrDefault();

is the equivalent of your first statement.

There will be a performance difference, because the methods are doing very different things under the hood. However, optimising purely in-memory operations is a bit pointless unless you are dealing with a large data set. If you are dealing with a large data set, then you should measure the performance of both alternatives rather than trying to predict which one will run faster.

Christian Hayter
  • 30,581
  • 6
  • 72
  • 99
  • except he works with huge xml files (like 1gig or bigger) - then he might want to do a benchmark (he should have a look at how to write a correct microbenchmark: http://stackoverflow.com/questions/504103/how-do-i-write-a-correct-micro-benchmark-in-java) – user181750 Oct 27 '09 at 09:27
  • @Christian: Is there any evidence that using XPathSelectElement has a "miniscule" performance difference. I'm not saying that it is not true but how is this known. The only way it could be miniscule is if the resulting XPath expression is compiled and cached. That is true of XPath in the System.Xml but is it the same in Linq-To-Xml? Is there some documentation or MS Team blog or some comparison tests posted on the web that bears this out? – AnthonyWJones Oct 27 '09 at 09:34
  • @rebugger: The larger the actual search operation the less significant the differences between the two approaches will be. There is no actual XPath search, only a parse of XPath to an equivalent LINQ-To-Xml expression. Of course if this code is run in a loop driven by the large XML then certainly the XPath approach would be slower. – AnthonyWJones Oct 27 '09 at 09:37
  • Not exactly equivalent - if the node is not found, document.Elements("actors").Elements("actor") will return an IEnumerable with Count() == 0, while document.XPathSelectElement("actors/actor") will return null – Webveloper Apr 03 '12 at 01:30
  • @Webveloper: You are correct, I've added an extra method to deal with that. – Christian Hayter May 28 '13 at 20:53
5

Seems like there is a hit, somebody else has done the benchmarking legwork: http://blog.dreamlabsolutions.com/post/2008/12/04/LINQ-to-XML-and-LINQ-to-XML-with-XPath-performance-review.aspx

roufamatic
  • 18,187
  • 7
  • 57
  • 86
2

From my limited testing, performance seems very similar. I took a sample XML message from http://msdn.microsoft.com/en-us/library/windows/desktop/ms762271(v=vs.85).aspx

XPath:

/book[id='bk109']

LINQ query:

from bookElement in xmlElement.Descendants( "book" )
where bookElement.Attribute( "id" ).Value == "bk109"
select bookElement

I then executed each 10,000 times (excluding the time it took to parse the string and the first run to eliminate the CLR noise).

Results (100,000 iterations)

  • XPath on XElement: 60.7 ms
  • LINQ to XML on XElement: 85.6 ms
  • XPath on XPathDocument: 43.7 ms

So, it seems that at least in some scenarios XPath evaluation on XElement performs better than LINQ to XML. XPath evaluations on XPathDocument are even faster.

But, it appears that loading an XPathDocument takes a little longer than loading an XDocument (1000 iterations):

  • Time to load XPathDocument: 92.3 ms
  • Time to load XDocument: 81.0 ms
Igor Pashchuk
  • 2,455
  • 2
  • 22
  • 29
2

Yes there will be although the two lines aren't equivalent.

The XPath needs to be parsed ultimately into a LINQ expression which would then do this:-

var x = document.Elements("actors").Elements("actor");

However its quite possible that internally a compiled version of the XPath expression is stored so that using an XPath only costs the time it takes to look up the string in some internally held dictionary. Whether that is actually the case or not I don't know.

AnthonyWJones
  • 187,081
  • 35
  • 232
  • 306