Jackson创始人Tatu Saloranta回应JSON基准测试_语言 & 开发_Matt Raible



 写点什么

上周，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：真实世界的行为和实际使用情况。我认为他们可能代表了使用情况的一小部分。说穿了，我觉得他们倾向于强调“好的例子”。我注意到三个方面：

输入源。最常被引用的测试都从 Java 字符串开始。字符串很少被当作输入源，因为它们是 JVM 构造，所有外部的输入都是字节流。单元测试中使用字符串，或者难道框架（或平台，也许 Groovy 这样做？）只公开字符串。对于写操作也是同样如此。这主要因为两件事情：（a）Jackson 对字节流或文件存储进行了深度优化，因为这是 REST 服务经常用的；（b）Boon 非常积极地优化字符串的处理，特别是使用 sun.misc.Unsafe 去访问和修改 String 类提供的底层的 char[]。因此，使用这些较少见，并且确实是 Boon 有明显优势（无可否认，这是更快的字符串）的用例作为使用源，看似有点可疑。

处理 / 访问风格：“无类型的（Untyped）”，处理 Map（而不是 POJO）的 List。这第二个方面虽然没那么可疑，但对我来说很奇怪，更不要说只对 List-of-Map 对象读和写，而不是真正的 POJO。所有现代的 JVM REST 框架都关注于 POJO，尽管有些也允许使用“无类型的”。不同的用户有不同的偏好；所以我认为只测试一种，或者测试两种，都是合法的，但这应该记录在案。

懒构建测试没有访问和校验数据。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：谢谢你的坦诚回应！