在 2025 收官前,看清 Data + AI 的真实走向,点击查看 BUILD 大会精华版 了解详情
写点什么

Jackson 创始人 Tatu Saloranta 回应 JSON 基准测试

  • 2014-05-19
  • 本文字数:1801 字

    阅读完需:约 6 分钟

上周,InfoQ 报道了 Groovy 2.3 的 JSON 解析器比之前的版本快了很多。当写那篇文章时,我们发了封邮件给 Jackson JSON 处理器的创始人 Tatu Saloranta 。我们想听听他对 Rick Hightower 报道的 Groovy 和 Boon 提供了 JVM 上最快的 JSON 解析器有什么看法。

InfoQ:你觉得那些基准测试是否准确?

Tatu Saloranta:在一个非常低的水平,我认为测试方法是一致的。JMH 是个好框架,使用适当的迭代计数等,结果是可以重复的。

我认为在某些或者很多测试中,Boon 和 Groovy 是有可能比 Jackson 更快的,但我确实对这种极端的声明表示怀疑,特别是这些挑选的特定测试和 / 或测试用例。

我的关注主要包括三个方面,都列在下一个问题的回答中。

此外,只是为了确认,我看到的是 GitHub 上的测试。我认为有很多的衍生工具,也许我的一些意见可能不太适用。

InfoQ:你认为这些基准测试是否反映了真实世界的行为?

TS:真实世界的行为和实际使用情况。我认为他们可能代表了使用情况的一小部分。说穿了,我觉得他们倾向于强调“好的例子”。我注意到三个方面:

  1. 输入源。最常被引用的测试都从 Java 字符串开始。字符串很少被当作输入源,因为它们是 JVM 构造,所有外部的输入都是字节流。单元测试中使用字符串,或者难道框架(或平台,也许 Groovy 这样做?)只公开字符串。对于写操作也是同样如此。这主要因为两件事情:(a)Jackson 对字节流或文件存储进行了深度优化,因为这是 REST 服务经常用的;(b)Boon 非常积极地优化字符串的处理,特别是使用 sun.misc.Unsafe 去访问和修改 String 类提供的底层的 char[]。因此,使用这些较少见,并且确实是 Boon 有明显优势(无可否认,这是更快的字符串)的用例作为使用源,看似有点可疑。
  2. 处理 / 访问风格:“无类型的(Untyped)”,处理 Map(而不是 POJO)的 List。这第二个方面虽然没那么可疑,但对我来说很奇怪,更不要说只对 List-of-Map 对象读和写,而不是真正的 POJO。所有现代的 JVM REST 框架都关注于 POJO,尽管有些也允许使用“无类型的”。不同的用户有不同的偏好;所以我认为只测试一种,或者测试两种,都是合法的,但这应该记录在案。
  3. 懒构建测试没有访问和校验数据。Boon 有不少面向输入懒处理的优化。对于只访问很小的数据子集的用例,这是有帮助的。但这儿的问题是性能测试没有做任何数据访问,事实上,解析器可能返回任何对象,而测试可能没有真正注意到这点。所以我觉得这些测试碰巧让懒处理得到了优化,正因为此,它们不代表你真的能得到这些优化。

也许我该重新整理一下上面所说的,这些测试似乎没有使用实际有效的使用模式,说得好听点是在做作。它们只读 / 写 JSON,但不使用它。我明白从某种角度来说这是有道理的,尽量不增加处理的开销,但不幸的是,由于不同的取舍,它歪曲了结果。所以当用户使用,例如 JAX-RS 风格的 REST 处理,InputStream 的所有 JSON 数据都绑定到 POJO;以及反方向的从其它 POJO 到 OutputStream,性能体验将与基准测试的结果完全不同。

另一方面,如果使用“无类型的”对象,至少代码要做某种形式的遍历;并且,如果同一对象要用于双向传递,同样要修改。

在 Boon 的例子中,叠置(Overlay)的使用(对原始输入进行索引,以便能够提取数据),以及 Map 的懒构造,隐藏了实际将遇到的真实开销。并且如果字符串用于源 / 目标,那么就存在编码 / 解码开销(Jackson 和 Boon 之间有区别,Jackson 这一步更重),这进一步降低了 Jackson 端到端的相对效率。

InfoQ:你有计划让 Jackson 将来更快吗?或者它已经“足够快”了?

TS:在这点上,我会做些小事情,但我没有大计划去关注性能。我希望能做一些研究(基准测试是有用的!)降低读取字符串源的消耗; Jackson Afterburner 模块已经有一些积极的优化。但这很可能是渐进式的。

自从最早的 1.x 版本开始,性能从来就不是第一目标;尽管我确实想保持开销适中或较低,但有更重要的事情要关注:易用性、支持其它格式(XML、CSV、CBOR 和 Smile)、惯例和模块化数据类型处理库(Joda,Guava)等等。

我想这应该是公平的,在正确的场景下,我觉得它非常接近于“足够快”。

InfoQ:谢谢你的坦诚回应!

TS:没问题,谢谢你发掘出这个。我认为总的来说 Boon 对 JSON 是有用的;特别是 Groovy 取得现代高性能支持,这非常棒。但我真的希望两者的比较是苹果对苹果的比较,同时声明应该有证据支持。:)

原文链接: Jackson Founder, Tatu Saloranta, responds to JSON Benchmarks

2014-05-19 02:214202

评论

发布
暂无评论
发现更多内容

如何在YashanDB数据库中执行复杂查询

数据库砖家

如何在YashanDB中实施数据治理策略

数据库砖家

如何在YashanDB中实现高效的数据查询与索引

数据库砖家

如何在多用户环境下有效运用YashanDB数据库

数据库砖家

深入分析YashanDB的数据建模技术与工具

数据库砖家

CST软件仿真超材料特性

思茂信息

cst操作 CST软件 CST Studio Suite

深度解析YashanDB的查询优化器工作原理

数据库砖家

深度解析YashanDB数据库中的内存管理与性能提升方法

数据库砖家

深度剖析YashanDB数据库查询优化的核心技术

数据库砖家

鸿蒙应用开发从入门到实战(十七):ArkUI组件List&列表布局

程序员潘Sir

鸿蒙

如何在YashanDB数据库中实现数据备份与恢复

数据库砖家

海外 App 的开发与上线流程

北京木奇科技有限公司

APP外包公司 海外APP 软件外包开发

如何在企业中实施YashanDB数据库迁移

数据库砖家

如何在YashanDB中实现高可用架构

数据库砖家

黑龙江2025年二级等保测评技术管理要求与监管机制

等保测评

云栖大会上,感受AI汽车的"乐与路"

科技汇

大数据-119 - Flink 窗口(Window)全解析:Tumbling、Sliding、Session 应用场景 使用详解 最佳实践

武子康

Java 大数据 flink spark 分布式

YashanDB数据库中使用分布式存储技术

数据库砖家

如何在YashanDB中实施实时数据分析策略

数据库砖家

YashanDB 内核调度机制与优化的一些深入分析

数据库砖家

哈尔滨 2025 年等保测评政策核心变革与实施要点

等保测评

深入分析YashanDB的行业细分应用

数据库砖家

如何在不同场景中灵活使用YashanDB

数据库砖家

如何在YashanDB数据库中实现高效的索引策略

数据库砖家

如何制定YashanDB数据库的性能基准测试计划

数据库砖家

深度剖析YashanDB数据库事件驱动架构的实现方法

数据库砖家

深入分析YashanDB的技术架构与创新

数据库砖家

深入分析YashanDB的聚合与筛选功能

数据库砖家

LED视频墙租赁:尺寸与分辨率的选择秘诀

Dylan

活动 LED LED display LED显示屏 LED屏幕

如何在YashanDB中实现高效的数据备份

数据库砖家

如何在YashanDB中实现高效查询与分析

数据库砖家

Jackson创始人Tatu Saloranta回应JSON基准测试_语言 & 开发_Matt Raible_InfoQ精选文章