Question

哪种XML结构允许我更快地添加，删除，更新节点？

我的假设是第一个，因为xml层次结构并不那么深。

你怎么看？

<Departments>
   <Department Id="a Guid" IsVisible="True" />
</Departments>

或

<Departments>
   <Department>
      <Id>a Guid</Id>
      <IsVisible>True</IsVisible>
   </Department> 
</Departments>

Answer 1

没关系。

您必须阅读整个文件并将其解析为文档结构，执行更新，然后编写整个文件。与文件I / O相比，更新对象结构的工作量很小，结构无关紧要。

Answer 2

我非常怀疑你会看到不同之处。 XML解析非常快。

你必须测试数十万甚至数百万条记录才能衡量差异，我认为这些记录很小。

Answer 3

找出哪一个更快的唯一方法是创建一些示例查询并在分析和平均时运行它们多次。我怀疑你会发现不同。

我会选择哪种架构更具表现力并满足您的要求。对我来说这是第一个，因为我怀疑你曾经想过一个Id或IsVisible类型。

Answer 4

这取决于您使用什么来添加，更新和删除。在所有条件相同的情况下，我会期待第一个，但是真的非常非常可以忽略不计。如果我发现某些库与第二个库的工作速度更快（由于内存模型表示的差异，完全是实现定义的），我甚至不会感到惊讶。

假设每个部门只有一个id和一个isVisible，我会去寻找第一个（没有被引用，修复的属性的bug），因为它有助于重新定义格式本身，并且是一个明确的适合。我不会因为不得不使用后者而感到沮丧。

Answer 5

一般

一般而言，我倾向于同意其他答案，但我想补充一些评论。当I / O是问题的一部分时，性能通常受其最慢因素的阻碍，即网络，数据库连接，文件系统甚至内部存储器。如果我们把它作为一个给定的，可能的结论是，尺寸越小，性能改进越大。

其他因素

但还有另一个因素。属性和元素的实现方式不同。属性实现类似于具有唯一性约束的键/值对，并且大致采用chars * 2 + sizeof(int)的大小。元素在内存中需要更大的结构，为了简洁起见，我喜欢使用一个简单的因子，它是几个实现之间的平均值：3.5 * chars。我在这里使用字符，因为无论你将它存储为UTF8还是UTF16都会产生存储差异，但不会产生内存差异。

前一段暗示属性更快。但这仍然不是一个简单的事实，因为属性不是作为普通节点实现的，搜索数据通常比在节点中搜索数据要慢。这一点很难衡量，需要对每个特定情况进行分析才能找到答案。

LINQ

然后就是LINQ。如果您使用LINQ，则使用流式XML完成读取和写入，这相对较快。与使用XmlDocument解析相比，内存中表示通常要小得多，速度也快得多。

姓名

字段名称的大小，如元素和属性无关紧要。在内部，他们是键控的，并给予一个唯一的ID。但是，元素和属性的内容将增加总体内存占用量。

如果名称的大小与其内容相比非常大，则缩小名称会降低XML的可读性，但也需要较少的I / O或网络带宽。因此，在某些情况下，它可能会提高使用小名称的性能。

UTF-8或UTF-16

最后，我应该在存储它的方式上添加一个注释。常识说，将其存储为UTF-8。但是这需要解析器读取每个字符并将其在内存中转换为UTF-16。这需要时间。有时，较大的文件大小（使用UTF-16）可以胜过较小的大小（使用UTF-8），因为处理器开销太大。再次，在几种情况下衡量您的表现可能会有所帮助哦，如果你使用很多（非常）高的字符，UTF-16应该是首选，因为UTF-8每个字符可能使用3个，4个甚至6个字节。

摘要

总结一下，如果速度是必要的，你就不能采用二进制格式：

首选属性而不是元素，但仅限于预期使用DOM并且搜索/键控不太重要;
仅当文件非常大并且您使用很少（非常）高的字符时，首选UTF-8而不是UTF-16，以便找出;
倾向于通过DOM进行流式传输以满足您的所有需求（LINQ通常使用流式传输）;
除非您的I / O确实是瓶颈且因素数据：开销非常大，否则不要使用小名称;
定义一些典型的使用场景和度量;

PS：以上是在考虑XML时会想到的，当然，还有很多其他因素会改善/降低性能，也许是你自己为CRUD操作编写最佳程序的最大技能。 / p>

哪个xml结构允许更快的添加/删除/更新

5 个答案:

一般

其他因素

LINQ

姓名

UTF-8或UTF-16

摘要