使用XmlDocuments,XSLT或Linq解析Xml,XPath的效率更高？

我使用以下两种方法解析了XML ...

使用对象模型和XPath查询解析XmlDocument.

XSL/T

但我从来没用过......

Linq Xml对象模型是.Net 3.5的新增功能

谁能告诉我三种替代方案之间的比较效率？

我意识到特定的用法是一个因素,但我只是想要一个粗略的想法.例如,Linq选项是否比其他选项慢得多？

1> Robert Rossn..：

---

查询XML文档的绝对最快的方法是最难的:编写一个使用XmlReader处理输入流的方法,并在读取它时处理节点.这是将解析和查询组合到单个操作中的方法.(简单地使用XPath不会这样做; XmlDocument和XPathDocument都会在其Load方法中解析文档.)如果您处理的是非常大的XML数据流,这通常只是一个好主意.

您描述的所有三种方法都表现相似.XSLT有很大的空间成为最慢的,因为它可以让你将XPath的低效率与模板匹配的低效率结合起来.XPath和LINQ查询基本上都是一样的,即通过可枚举的XML节点列表进行线性搜索.我希望LINQ在实践中稍微快一些,因为XPath是在运行时解释的,而LINQ是在编译时解释的.

但总的来说,编写查询的方式对执行速度的影响要大于使用的技术.

无论您是使用XPath还是LINQ,编写快速查询XML文档的方法都是相同的:制定查询以便在执行期间尽可能少地访问该节点.使用哪种技术无关紧要:检查文档中每个节点的查询运行速度要慢于仅检查其中一小部分节点的查询.您执行此操作的能力更依赖于XML的结构而不是其他任何内容:具有可导航元素层次结构的文档通常比其元素都是文档元素的子元素的查询要快得多.

编辑:

虽然我很确定我是对的,查询XML的绝对最快的方法是最难的,真正最快(最难)的方式是不使用XmlReader; 它使用一个直接处理流中字符的状态机.就像使用正则表达式解析XML一样,这通常是一个糟糕的主意.但它确实为您提供了交换速度功能的选项.通过决定不处理您的应用程序不需要的那些XML(例如命名空间解析,字符实体的扩展等),您可以构建一些能够比通过更快速地搜索字符流的内容XmlReader.我可以想到应用程序,这甚至不是一个坏主意,虽然我想不到很多.

---

.NET 4.0中PLINQ(Parallel Linq)的可用性使Linq成为比以前更加引人注目的选择.公平地说,PLINQ真的只是在这个问题上投入了更多的马力; 它不会使解析器更有效率.但总体而言,Linq在简洁和性能之间取得了很好的平衡.