XPathSelectElement 与后代答案

【问题标题】：XPathSelectElement vs DescendantsXPathSelectElement 与后代
【发布时间】：2009-10-27 09:16:25
【问题描述】：

我想知道在使用 simple 查询时是否有任何性能差异：

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

vs

var x = document.Descendants("actors").Descendants("actor")

【问题讨论】：

旁注：这个问题的答案忽略stackoverflow.com/questions/3705020/… - 第二个查询将返回像“/foo/actors/random_nodes/actor”这样的节点，不像第一个只返回“actor”，它是直接子节点“演员”。

【解决方案1】：

注意这个

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

相当于你的第一个语句。

会有性能差异，因为这些方法在后台做的事情非常不同。但是，除非您正在处理大型数据集，否则优化纯粹的内存操作有点毫无意义。如果您正在处理一个大型数据集，那么您应该衡量两种备选方案的性能，而不是试图预测哪一种会运行得更快。

【讨论】：

除非他使用巨大的 xml 文件（比如 1gig 或更大）——然后他可能想做一个基准测试（他应该看看如何编写一个正确的微基准测试：stackoverflow.com/questions/504103/…）跨度>
@Christian：是否有任何证据表明使用 XPathSelectElement 具有“微小”的性能差异。我不是说这不是真的，但这是怎么知道的。它可能很小的唯一方法是编译和缓存生成的 XPath 表达式。 System.Xml 中的 XPath 也是如此，但在 Linq-To-Xml 中是否相同？是否有一些文档或 MS Team 博客或网络上发布的一些比较测试证明了这一点？
@rebugger：实际搜索操作越大，两种方法之间的差异就越不显着。没有实际的 XPath 搜索，只是将 XPath 解析为等效的 LINQ-To-Xml 表达式。当然，如果这段代码在由大型 XML 驱动的循环中运行，那么 XPath 方法肯定会更慢。
不完全等效 - 如果未找到节点，则 document.Elements("actors").Elements("actor") 将返回一个 IEnumerable 与 Count() == 0，而document.XPathSelectElement("actors/actor") 将返回 null
@Webveloper：你说得对，我已经添加了一个额外的方法来处理这个问题。

【解决方案2】：

【讨论】：

【解决方案3】：

是的，虽然这两行不等价。

最终需要将 XPath 解析为 LINQ 表达式，然后执行以下操作：-

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

但是很有可能内部存储了 XPath 表达式的编译版本，因此使用 XPath 只花费在某些内部保存的字典中查找字符串所需的时间。是不是真的不知道。

【讨论】：

【解决方案4】：

从我有限的测试来看，性能似乎非常相似。我从http://msdn.microsoft.com/en-us/library/windows/desktop/ms762271(v=vs.85).aspx获取了一个示例 XML 消息

XPath：

/book[id='bk109']

LINQ 查询：

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

然后我每执行 10,000 次（不包括解析字符串和第一次运行以消除 CLR 噪声所花费的时间）。

结果（100,000 次迭代）

因此，至少在某些情况下，对 XElement 的 XPath 评估似乎比 LINQ to XML 执行得更好。 XPathDocument 上的 XPath 评估甚至更快。

但是，加载 XPathDocument 似乎比加载 XDocument（1000 次迭代）需要更长的时间：

【讨论】：