更快的多重解析：SAX 或 DOM

Posted 2023-02-24

【中文标题】更快的多重解析：SAX 或 DOM

【英文标题】：faster multiple parsings : SAX or DOM

【发布时间】：2013-09-03 20:53:28

【问题描述】：

我读过很多帖子说 SAX 比 DOM 快。我不确定我的问题是否愚蠢，但我认为如果我们有巨大的内存，DOM 必须更快。因为一旦将树结构加载到内存中，它应该比 SAX 更快。

我在这里需要一些澄清，请帮助我理解。 我有一个用例，我每天都会收到一个要解析多次的大文件。 我可以说 DOM 在第一次解析时可能会比 SAX 慢一点，并且所有后续解析在 DOM 的情况下会非常快，因为它将整个文档结构加载到内存中并重用它。如果是这样，那我们怎么能说 SAX 比 DOM 快。如果我错了，请纠正我。 如果明天我更改我的 XSD 并需要将新结构推送到内存中，那么有没有办法在不重新启动应用程序的情况下做到这一点。

【参考方案1】：

我们在以下情况下使用 SAX：

我们该死的确定，只需通过文件一次就足够了。顺便说一句，大多数时候都是这样。执行多次传递或返回/转发指针的代码大多数时候可以重构为一次传递。

当我们通过某些流媒体渠道（例如通过网络）接收 xml 文件时，我们可能希望在整个文件完全下载之前进行实时读取。 SAX 可以处理部分下载的文件，DOM 不能。

当我们对 XML 中的特定位置感兴趣时，而不是对完整文档感兴趣。例如，Atom Feed 最适合 SAX，但要分析 WSDL，您将需要 DOM。

我们在以下情况下使用 DOM：

好吧，当单次通过时不行。我们需要在文件中上下移动。

当 XML 在磁盘上并且我们不需要实时读数时。我们可以慢慢来，加载 它，阅读它，分析它，然后得出结论。

当你的老板要求在午餐前做，而你不打扰质量。

现在回答你的问题

您提供了：

你有一个巨大的文件：........SAX +1 解析多次：.....DOM +1

两者都获得相同的选票。将您现有的知识库添加到其中。 （熟悉 SAX？）。巨大有多大？您所说的 XML 和内存都很大。即使是 100MB 的文件也没什么大不了的。 DOM 可以处理它。您需要每天解析多次。如果一个操作在几分钟内完成，那么将数据保留在内存中接下来的几个小时似乎并不明智。在这种情况下，您将失去 DOM 的好处。但是如果一个操作本身需要一个小时，那么您保留预处理信息是完全正确的。

正如我所指出的，您没有提供足够的统计数据。统计数据大小、内存大小、DOM 中的加载时间、处理时间，您一天究竟需要多少次？您的机器在此期间做什么？闲置或分析其他此类文件？

获取这些统计信息。要么在这里发布，要么自己分析它们，你就会得出结论。

【讨论】：

如果这一切看起来太过分了，那就去 DOM。

谢谢。文件大小约为 6-7 mb. 一天三次。我们被要求在性能上给予最高优先级。但我仍然不清楚如果我们有足够的内存并且一旦第一次完成解析，那么对于所有后续解析 SAX 如何获得平等票数。 如果DOM在加载到内存后不重用文档结构，请纠正我

@Johnn，请统计一下。做一次。在 DOM 中加载您的 xml 并执行一些基本操作，获取一些您感兴趣的值。您现在不需要编写整个程序。只是一个基本骨架。看看需要多长时间。如果花费的时间超过几分钟，那么您需要查看 SAX，但低于该 SAX 将是矫枉过正。如果您有足够的时间，请继续使用 SAX 进行类似的实验。统计数据应该告诉你。不是我也不是其他人。

DOM 确实会在将文档结构加载到内存后重用它。但是那个结构占据了空间。 DOM 文档的内存占用大约是磁盘大小的三倍。您必须整天占用 7x3=21 MB 的内存。现在，如果您的机器碰巧解析了更多这样的文档，它很快就会爬网。每次需要时花费一些 cpu 并重新生成该结构会更明智。内存开销远远超过 CPU 开销。