写点什么

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:213652

评论

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

2022 IoTDB Summit:京东刘刚《Apache IoTDB 在京东万物互联场景中的应用》

Apache IoTDB

大数据 时序数据库 IoTDB

DockQuery x 达梦 国产数据库生态“加速跑”

BinTools图尔兹

#数据库 信创产业 达梦认证

一万年太久,只争朝夕 | Foundation model的进展仍不够快

Baihai IDP

人工智能 AI 大模型 企业号 3 月 PK 榜 Foundation Models

从传统数据库痛点看分布式数据库选型问题

OceanBase 数据库

云原生应用配置管理的5个最佳实践

HummerCloud

云原生

软件测试 | 常见覆盖率统计工具

测吧(北京)科技有限公司

测试

软件测试 | 代码分析的持续集成应用

测吧(北京)科技有限公司

测试

从青铜到王者,揭秘 Serverless 自动化函数最佳配置

Serverless Devs

Serverless 云原生

详解Docker容器运行GUI程序的方法

华为云开发者联盟

开发 华为云 华为云开发者联盟 企业号 3 月 PK 榜

软件测试 | 精准化测试

测吧(北京)科技有限公司

测试

高并发场景下,如何优化服务器的性能

华为云开发者联盟

高并发 开发 华为云 华为云开发者联盟 企业号 3 月 PK 榜

企业是否具备等保测评资质在哪里查?怎么查?

行云管家

等保 等级保护 等保测评

某游戏公司基于OceanBase 4.0的运营分析AP实践

OceanBase 数据库

秒懂算法 | 基于主成分分析法、随机森林算法和SVM算法的人脸识别问题

TiAmo

机器学习 算法 随机森林

双机热备三个优势简单说明-行云管家

行云管家

负载均衡 高可用 服务器 双机热备

2022 IoTDB Summit:中航王闯《Apache IoTDB 在中航机载智能云制造系统的应用解决方案》

Apache IoTDB

数据库 大数据 IoTDB

FTP上传文件速度太慢怎么办?

镭速

flutter系列之:在flutter中自定义themes

程序那些事

flutter 架构 大前端 Web 程序那些事

用友BIP事项会计 X 全面预算:多维数智预算助力企业敏捷算赢未来

用友BIP

智能会计

超越ChatGPT:大模型的智能极限

OneFlow

人工智能 深度学习 ChatGPT

软件测试 | Sonarqube中的覆盖率分析

测吧(北京)科技有限公司

测试

户外led显示屏在安装设计指南

Dylan

LED显示屏 户外LED显示屏 户内led显示屏

面向增长,用友招聘云发布新一代人才配置解决方案!

用友BIP

人才 平台 招聘管理系统

2023最新后端中大厂面经&在面试过程中如何反问?

王中阳Go

高效工作 学习方法 面试 面试题 大厂面经

零信任分段如何防止内网漫游?

权说安全

零信任

Node.js 未来发展趋势

京东科技开发者

Java 机器学习 前端 物联网 nodejs

基于 eBPF 的 Serverless 多语言应用监控能力建设

Serverless Devs

Serverless

IntelliJ IDEA中提高代码开发效率的10个快捷操作

京东科技开发者

var java 企业号 3 月 PK 榜 psvm sout

2022 IoTDB Summit:长安汽车黄立《Apache IoTDB 在长安智能汽车数据平台的实践》

Apache IoTDB

sequence:从认识到会使用,今儿给你讲的透透的

华为云开发者联盟

数据库 后端 华为云 华为云开发者联盟 企业号 3 月 PK 榜

Serverless 时代开启,云计算进入业务创新主战场

Serverless Devs

Serverless

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