Jackson 2.15: faster floating-point writes, too

3 min readApr 21, 2023

After writing my earlier post — “Jackson 2.15: faster floating-point reads” — I was reminded that it is not just reads: there has been support for faster writing of floating-point numbers too. This improvement was also include in Jackson 2.14 release, optionally enabled using matching feature JsonWriteFeature.USE_FAST_DOUBLE_WRITER.

But as with reads, while support for optional optimized handling was announced, we had no supporting evidence on expected positive effects. So let’s see how writer-side works.

Test Setup

As with reading tests, we’ll add test cases in jackson-benchmarks project using the same Awesome JSON Datasets sample content.

Test were run on my home Mac Mini 2018 (3.2 ghz, 6 core Intel), with both JDK 8 (1.8.0_362) and 17 (Temurin 17.0.4.1), using SDKMan to switch between versions.
Typical invocations after building (mvn clean package after git clone ing jackson-benchmarks repo) look something like:

java -Xmx256m -jar target/perf.jar ".*Json.*StdWriteVanilla.writeCurrencyPojo.*" -wi 3 -w 1 -i 5 -r 1 -f 5

TL; DNR: +20 — +30% throughput for JSON

Compared to reading, writing is actually improved more: with JDK 8 we get about 20% improvement:

Benchmark                                      Mode  Cnt      Score     Error  Units
JsonStdWriteVanilla.writeCurrencyPojoDefault  thrpt   25  56956.808 ± 692.258  ops/s
JsonStdWriteVanilla.writeCurrencyPojoFast     thrpt   25  67980.186 ± 431.886  ops/s

and with JDK 17 almost 30%:

Benchmark                                      Mode  Cnt      Score      Error  Units
JsonStdWriteVanilla.writeCurrencyPojoDefault  thrpt   25  55172.044 ±  434.920  ops/s
JsonStdWriteVanilla.writeCurrencyPojoFast     thrpt   25  69496.599 ± 1300.986  ops/s

which is pretty nice, for something you get sort of “for free”.

While I have not tried to correlate improvements to other costs of serialization (writing), I think this is in line with maybe 2x faster low-level writes.

JSON vs Binary formats for FP writes

With floating-point number reads JSON had more overhead than binary formats — took about 2x as long for same logical content. But how about writing?

Turns out the difference is MUCH bigger for writing, for some reason :

Benchmark                                                     Mode  Cnt       Score       Error  Units
java -Xmx256m -jar target/perf.jar ".*StdWriteVan.*writeCurrencyPojo.*" -wi 4 -w 1 -i 5 -r 1 -f 5
c.f.j.p.cbor.CBORStdWriteVanilla.writeCurrencyPojoDefault    thrpt   25  333055.712 ± 13589.371  ops/s
c.f.j.p.json.JsonStdWriteVanilla.writeCurrencyPojoDefault    thrpt   25   56707.088 ±   450.002  ops/s
c.f.j.p.json.JsonStdWriteVanilla.writeCurrencyPojoFast       thrpt   25   67469.997 ±   649.434  ops/s
c.f.j.p.smile.SmileStdWriteVanilla.writeCurrencyPojoDefault  thrpt   25  206126.259 ±  2291.091  ops/s

So: writing CBOR is about 5 TIMES as fast as JSON; and Smile 3–4 times as fast (difference between CBOR and Smile is actually quite interesting as well; I would not have expected that big difference here).

I am bit surprised here; somehow I was just assuming that reading textual representation into binary FP would have more overhead than writing — but this is not the case.
For perspective, writing other kinds of JSON is about 2x as fast as reading, so the fact that read and write tests with FP for JSON have similar throughput suggests that FP-from-String is about 3x as fast as FP-to-String.
TILT!

Possible Future Work

It would be interesting to profile to see what is the deal between CBOR and Smile here. There is slight performance benefit for other content (that “MediaItem” POJO test from jvm-serializers) — maybe +15% — but here there is +50% throughput edge. This is quite interesting; perhaps this is due to Smile’s use (by default) of avoiding of using null bytes, so FP values get encoded as 10 / 5 bytes (instead of minimal 8 / 4 when using full range).

It would also make sense to further profile to see if the optimized textual FP implementation (“Schubfach”) could be further optimized in our case.
And perhaps work with its author.

Stay Tuned for Jackson 2.15

In a related note, Jackson 2.15.0 should be released soon! There is still time to play with 2.15.0-rc3 and report bugs but time is running out.

And I do hope to write something about 2.15 feature set before 2.15.0 is released.
Thank you for reading so far!