11

有点相关：来自 java 的 libxml2

是的，这个问题相当冗长 - 抱歉。我保持尽可能密集。我将问题加粗，以便在阅读整个内容之前更容易窥视。

为什么sax解析比dom解析快？ 我唯一能想到的是，使用 sax 您可能会忽略大部分传入数据，因此不会浪费时间处理您不关心的部分 xml。IOW - 使用 SAX 解析后，您无法重新创建原始输入。 如果您编写了 SAX 解析器，以便它解释每个 xml 节点（并因此可以重新创建原始节点），那么它不会比 DOM 快吗？

我问的原因是我试图更快地解析 xml 文档。我需要在解析后访问整个 xml 树。我正在为要插入的第 3 方服务编写一个平台，因此我无法预测需要 xml 文档的哪些部分以及不需要哪些部分。我什至不知道传入文档的结构。这就是我不能使用 jaxb 或 sax 的原因。内存占用对我来说不是问题，因为 xml 文档很小，我一次只需要 1 个内存。解析这个相对较小的 xml 文档需要花费时间，这让我很头疼。我以前没有使用过 stax ，但也许我需要进一步调查，因为它可能是中间立场？ 如果我理解正确， 这样一来，原来的解析时间可能会很快，但是每次我要求它遍历它尚未遍历的树的一部分时，那是处理发生的时间吗？

如果您提供回答大部分问题的链接，我将接受您的回答（如果我的问题已经在其他地方得到回答，您不必直接回答我的问题）。

更新：我用 sax 重写了它，它解析文档的时间平均为 2.1 毫秒。这是 dom 所花费的 2.5 毫秒的改进（快 16%），但这不是我（等人）猜到的幅度

谢谢

4

4 回答 4

15

假设你只解析文档，不同解析器标准的排名如下：

1. StAX 是最快的

  • 事件报告给你

2. SAX 是下一个

  • 它完成了 StAX 所做的一切以及自动实现的内容（元素名称、命名空间、属性……）

3. DOM 是最后的

  • 它完成 SAX 所做的一切并将信息呈现为 Node 的实例。

您的用例

  • 如果需要维护所有的 XML，DOM 是标准表示。它与 XSLT 转换(javax.xml.transform )、XPath ( javax.xml.xpath ) 和模式验证 ( javax.xml.validation ) API 完美集成。但是，如果性能是关键，您可以使用 StAX 构建自己的树结构，速度比 DOM 解析器构建 DOM 的速度要快。
于 2010-09-29T20:03:03.887 回答
12

DOM 解析需要你将整个文档加载到内存中，然后遍历一棵树来找到你想要的信息。

SAX 只需要执行基本 IO 所需的内存，并且可以在读取文档时提取所需的信息。因为 SAX 是面向流的，所以您甚至可以处理仍在由另一个进程写入的文件。

于 2010-09-29T19:42:02.340 回答
12

SAX 更快，因为 DOM 解析器通常使用 SAX 解析器在内部解析文档，然后执行创建和操作对象以表示每个节点的额外工作，即使应用程序不关心它们。

直接使用 SAX 的应用程序可能比 DOM“解析器”更有效地利用信息集。

StAX 是一种令人愉快的媒介，应用程序获得比 SAX 的事件驱动方法更方便的 API，但不会遭受创建完整 DOM 的低效率。

于 2010-09-29T19:42:47.503 回答
2

SAX 比 DOM 快（通常在读取大型 XML 文档时会感觉到），因为 SAX 以事件序列的形式提供信息（通常通过处理程序访问），而 DOM 创建节点并管理节点创建结构，直到完全创建 DOM 树（如在 XML 文档中表示）。

对于相对较小的文件，您不会感觉到效果（除了可能由 DOM 完成额外处理以创建节点元素和/或节点列表）。

我无法对 StAX 发表评论，因为我从未玩过它。

于 2010-09-29T20:02:22.430 回答