什么是 xml 解析更快：元素还是属性？答案

【问题标题】：What is faster in xml parsing: elements or attributes?什么是 xml 解析更快：元素还是属性？
【发布时间】：2010-11-22 19:14:24
【问题描述】：

我正在编写解析 XML 的代码。

我想知道什么是更快的解析：元素或属性。

这将对我的 XML 设计产生直接影响。

请针对 C# 的答案以及 LINQ 和 XmlReader 之间的区别。

谢谢。

【问题讨论】：

性能不应该是您设计 XML 格式时的主要目标，除非您真的遇到问题。
如果您真的需要速度，请不要使用 XML。使用 JSON 之类的东西，它更容易解析，或者使用某种形式的二进制序列化。
一个更好的问题是哪个更适合作为信息的表示？
不要编写代码来解析 XML。它比看起来更难。如果您只使用看起来像 XML 但实际上不是 XML 的东西，那很好，也很常见。
@Steve Townsend：OP 不会编写自己的解析器。而且我认为拥有“看起来像 XML 但实际上不是 XML 的东西”远非很好，因为没有标准工具能够处理它。实际上，如果您必须在遗留应用程序中处理这种格式，那么这种格式真的很痛苦。

标签： c# xml linq benchmarking xmlreader

【解决方案1】：

设计您的 XML 模式，使信息的表示真正有意义。通常，在属性或元素之间做出决定不会影响性能。

XML 的性能问题在大多数情况下都与以非常冗长的 XML 方言表示的大量数据有关。一个典型的对策是在通过网络存储或传输 XML 数据时对其进行压缩。

如果这还不够，那么切换到另一种格式，如 JSON、ASN.1 或自定义二进制格式可能是可行的方法。

解决您问题的第二部分：XDocument (LINQ) 和 XmlReader 类之间的主要区别在于 XDocument 类在内存中构建完整的文档对象模型 (DOM)，这可能是一个昂贵的操作，而 XmlReader 类在输入文档上为您提供了一个标记化的流。

【讨论】：

-1。只要信息有一个模式（即使它只是在你的脑海中而不是明确的），它可能是二进制格式并且仍然有意义（例如，固定字节大小的记录或其他任何东西）。重要的不是它是如何存储的，而是解析器希望你如何存储它。您的回答是一个转移话题，将问题从“什么是更快，属性或元素”转移到“谁在乎真相，如果您因为 xml 有性能问题，您应该重新设计您的架构，因为它不应该导致性能问题”。问题是真的，这里不充分。

【解决方案2】：

对于 XML，速度取决于很多因素。

关于属性或元素，选择与数据更匹配的那个。作为指导，我们将属性用于对象的属性。以及包含的子对象的元素。

根据您谈论的数据量，使用属性可以为您节省一些 xml 流的大小。例如，<person id="123" /> 小于 <person><id>123</id></person> 这不会真正影响解析，但会影响通过网络线路发送数据或从磁盘加载数据的速度......如果我们谈论的是数千个这样的记录，那么它可能会对您的应用程序产生影响。

当然，如果这确实有所作为，那么使用 JSON 或一些二进制表示可能是更好的方法。

您需要问的第一个问题是是否需要 XML。如果它不需要人类可读，那么二进制可能会更好。哎呀，CSV甚至固定宽度的文件可能会更好。

关于 LINQ 与 XmlReader，这将归结为您在解析数据时如何处理数据。您是否需要实例化一堆对象并以这种方式处理它们，还是只需要读取传入的流？您甚至可能会发现仅对数据进行基本的字符串操作可能是最简单/最好的方法。

重点是，您可能需要检查每种方法的优势，而不仅仅是“什么解析得更快”。

【讨论】：

【解决方案3】：

没有任何确凿的数字来证明这一点，我知道 Microsoft 的 WCF 团队选择将 DataContractSerializer 作为 WCF 的标准。它的局限性在于它不支持 XML 属性，但它确实比 XmlSerializer 快了 10-15%。

根据这些信息，我认为使用 XML 属性解析比只使用 XML 元素要慢。

【讨论】：