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 回答