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

Posted

技术标签:

【中文标题】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 解析器”,***.com/questions/530064/… 看看这篇 2013 年的论文,它做了很多基准测试sdiwc.us/digitlib/journal_paper.php?paper=00000582.pdf 【参考方案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 更快)

以上是关于Java 中是不是有比 Xalan/Xerces 更快的 XML 解析器 [关闭]的主要内容,如果未能解决你的问题,请参考以下文章

在 Hibernate 中进行分页是不是有比执行选择和计数查询更有效的方法?

在这种情况下,是不是有比 if-else 更快的替代方法?

对于 MySQL 请求,是不是有比 ASyncTask 更好的类或库? [关闭]

JSF 2.0 有比 Icefaces 更好的 Ajax Push

如果值是对象并且这些对象的属性是键,是不是有比 Dictionary 更好的数据结构?

在 SQL Server 数据库之间移动数据行是不是有比使用 CTE 更快的方法?