Java 中是否有比 Xalan/Xerces 更快的 XML 解析器 [关闭]答案

【问题标题】：Are there faster XML parsers in Java than Xalan/Xerces [closed]Java 中是否有比 Xalan/Xerces 更快的 XML 解析器 [关闭]
【发布时间】：2010-10-31 21:57:09
【问题描述】：

除了利用诸如 Tarari 或 Datapower 之类的硬件之外，我还没有找到很多方法来提高执行密集 XML 处理的 Java 应用程序的性能。有谁知道加速 XML 解析的任何开源方法？

【问题讨论】：

如果您详细说明您正在执行哪种 XML 处理，您将获得更好的答案。您是否受到特定 API (DOM) 的限制？您需要在内存中存储多少 XML？您需要支持多少种不同的模式？你能相信 XML 是有效的吗？..
相关问题：“Java 中用于小型简单文档的最快 XML 解析器”，stackoverflow.com/questions/530064/…
看看这篇 2013 年的论文，它做了很多基准测试sdiwc.us/digitlib/journal_paper.php?paper=00000582.pdf

标签： java xml performance parsing

【解决方案1】：

由于没有直接提及，我将输入Aalto，根据一些测量，这是最快的java xml解析器，例如：

JVM-serializers（比较 XML、JSON、protobuf、Thrift 等）
Alternative serialization methods for WSTest（Java 网络服务）

不是由 Aalto 开发人员编写的。

【讨论】：

【解决方案2】：

VTD-XML 非常快。

它有一个类似 DOM 的 API，甚至还有 XPath 查询。

【讨论】：

【解决方案3】：

看看 Stax（流）解析器。见the sun reference manual。其中一种实现是woodstox project。

【讨论】：

xml.com/pub/a/2007/05/09/xml-parser-benchmarks-part-1.html 很好地概述了 XML 解析器的速度。伍德斯托克斯看起来不错。
STAX 是最佳选择，Woodstox 速度很快。
Wrt VTD vs Stax，真的应该尝试一下。 Stax 是一个 API，所以不同的实现有不同的性能。并且 VTD-XML 的权衡有点不同——解析更快，访问更慢（一些操作只在访问时进行，比如处理字符实体）。
不支持随机访问，Stax 解析速度慢，访问速度慢，实体处理与 dom 几乎没有区别......这是一个容易记住的事实......

【解决方案4】：

也检查Javolution

【讨论】：

我不同意。 Javolution 的 XML“解析器”不检查 xml 的任何问题（重复属性），不处理名称空间，不实现任何标准 API。而且速度也不快。
@StaxMan 好的一面是它在解析过程中不会产生太多垃圾，而且有时能够读取格式错误的 XML 是一种奖励
超低垃圾产生的价值在大多数平台上是一个悬而未决的问题；无论如何，大多数流解析器在对象生成方面都非常节俭。如果你觉得它有用，对你有好处。在这种情况下，我还没有看到它的重要性。至于无效的 XML，我认为最好不要能够处理它并向破坏事物的生产者施加反压力。但 YMMV，各有所长。

【解决方案5】：

根据您的 XML 消息的复杂性，您可能会发现自定义解析器的速度可以提高 10 倍（尽管需要编写更多工作）但是如果性能至关重要，我不建议使用通用解析器。（另外我不建议使用 XML，因为它不是为性能而设计的，但这是另一回事，.. ;)

【讨论】：

编写自定义 XML 解析器是一个耗时且容易出错的过程。获得正确的 XML 并不容易，尤其是当您想解析 XML 文档时。 (cafeconleche.org/SAXTest)
这都是真的，这就是为什么它在大多数时候都不是一个好主意。但是，如果速度很关键，您可以获得 10 倍的改进。
嗯？你有没有真正尝试过这样做？编写一个更快的自定义解析器并非易事。最快的现有解析器以 30-60 MBps 的速率解析；不会比解码纯 UTF-8 文本慢多少。 10x，没办法，绝对不行。随意尝试，获得一些数字。 :-)
我强烈希望速度的任何提升都伴随着一些工作不需要做的知识。
@Thorbjørn 自定义解析器通过调整到特定的 XMl 格式而获益。这在大多数情况下并不适用，但您可以看到显着的改进。通过改进，我的意思是延迟而不是吞吐量。通过减少工作量，吞吐量可能会提高 2 倍。

【解决方案6】：

Piccolo 声称是pretty fast。不能说我自己用过。你也可以试试JDOM。与以往一样，使用您的真实负载的代表性数据进行基准测试。

这部分取决于您想要做什么。是否需要将整个文档拉入内存，还是可以在streaming manner 中操作？不同的方法有不同的取舍，并且更适合不同的情况。

【讨论】：

Piccolo 似乎以速度换取正确性，这可能是也可能不是您想要的。 (cafeconleche.org/SAXTest/paper.html#S4.2.4)
平心而论，偏差不太可能影响性能很重要的情况（往往是简单的（r）用例）——SAXTest 倾向于关注 DTD 使用和正确性的复杂情况。但另一方面，虽然 Piccolo 可能在 2004 年更快，但它并没有得到太多开发，其他人已经赶上了，有些甚至超过了它（Xerces 和 Woodstox 一样快，尤其是 Aalto 更快）