我使用以下两种方法解析了 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 是在编译时解释的。
但总的来说，你如何编写查询对执行速度的影响将比你使用的技术大得多。
无论您使用的是 XPath 还是 LINQ，针对 XML 文档编写快速查询的方法都是相同的：制定查询，以便在执行期间尽可能少地访问节点。 使用哪种技术并不重要：检查文档中每个节点的查询的运行速度比仅检查其中一小部分节点的查询慢得多。 您执行此操作的能力比其他任何内容都更依赖于 XML 的结构：具有可导航元素层次结构的文档通常比其元素都是文档元素的子级的文档查询要快得多。
编辑：
虽然我很确定我是对的，查询XML的绝对最快方法是最难的，但真正最快(也是最难(的方法不使用XmlReader;它使用直接处理流中字符的状态机。 就像使用正则表达式解析 XML 一样，这通常是一个糟糕的主意。 但它确实为您提供了交换速度的功能的选项。 通过决定不处理应用程序不需要的那些 XML 片段(例如命名空间解析、字符实体的扩展等(，您可以构建比XmlReader更快地通过字符流进行查找的内容。 我可以想到这甚至不是一个坏主意的应用程序，尽管我想不出很多。
LinqToXml 查询针对 IEnumerable 协定工作...它的大部分操作都是 O(N(，因为它们需要对 IEnumerable 进行迭代。
如果你从一个包含 xml 的字符串开始，为了在 Linq 中使用它，你需要使用 XElement.Parse 将其解析为完整的对象图，然后迭代它的一部分(例如，过滤它(。
我对 XPath 的理解是它会在解析时进行过滤，从性能的角度来看，这可能是非常有利的。 不需要构建完整的对象图。
我还没有实际测试过它，但 Linq 主要是一个编译器代码生成类型的功能，因此它应该与使用 XmlDocument 和 XPath 查询相当。
Linq 的主要价值在于它提供查询语句的编译时验证，而 XPath 和 XSLT 都无法提供这种验证。
我认为，如果性能是一个问题，您的决定将基于手头的任务。 例如，使用单个 XPath 查询从 XML 文档中检索单个值可能最快，但使用 XSLT 将 XML 数据转换为 HTML 页会更快。
如果你想要真正快速的XML处理(读取(，你应该考虑使用XmlReader，不幸的是实现有点困难。
还有一种方法可以使用 XmlReader 的组合来实现 LINQ 解决方案，以便您可以轻松使用 LINQ。此外，您还可以获得比 XmlDocument/XPath 更好的性能。
请参阅以下链接以获取更多信息。http://blogs.msdn.com/xmlteam/archive/2007/03/24/streaming-with-linq-to-xml-part-2.aspx
另外，我认为如果您只使用XmlDocument/XPath处理小型XML文件，则不会成为性能问题。