.net – 用XmlDocuments,XSLT或Linq解析Xml,XPath更有效率吗？

我已经解析XML使用以下两种方法…

>使用对象模型和XPath查询解析XmlDocument。
> XSL / T

但我从来没有使用过…

> .Net 3.5的新的Linq Xml对象模型

任何人都可以告诉我三种替代品之间的比较效率？

我意识到，特定的用法将是一个因素，但我只是想一个粗略的想法。例如，Linq选项是否比其他选项更慢？

查询XML文档的绝对最快的方法是最困难的：编写一个方法，使用XmlReader来处理输入流，并在读取它们时使它处理节点。这是将解析和查询合并为单个操作的方式。 (简单地使用XPath不这样做; XmlDocument和XPathDocument都在它们的Load方法中解析文档。)如果你处理极大量的XML数据流，这通常只是一个好主意。

您描述的所有三个方法执行类似。 XSLT有很多空间是最慢的，因为它让你结合XPath的低效率与模板匹配的低效率。 XPath和LINQ查询本质上都是相同的事情，这是通过XML节点的可枚举列表的线性搜索。我希望LINQ在实践中略微更快，因为XPath是在运行时解释，而LINQ在编译时解释。

但是一般来说，如何编写查询将比使用什么技术对执行速度有更大的影响。

针对XML文档编写快速查询的方法是相同的，无论是使用XPath还是LINQ：制定查询，以便尽可能少的节点在执行期间访问。使用哪种技术无关紧要：检查文档中每个节点的查询的运行速度比仅检查其中一小部分的查询慢得多。你做这件事的能力更多取决于XML的结构，比其他任何事情：具有可导航的元素层次结构的文档通常比元素是文档元素的所有子元素的查询要快得多。

编辑：

虽然我很肯定我是对的，查询XML是绝对最快的方式是最难的，真正最快(和最难的)方式不使用XmlReader;它使用直接处理流中的字符的状态机。像使用正则表达式解析XML一样，这通常是一个可怕的想法。但它确实给你选择交换功能的速度。通过决定不处理您的应用程序不需要的那些XML片段(例如命名空间解析，字符实体扩展等)，您可以构建一些东西，通过比XmlReader更快的字符流来寻找。我可以想到的应用程序，这甚至不是一个坏主意，虽然我不能想到很多。