No-allocation DoubleToDecimal / FloatToDecimal

[westinrm]

OpenJDK25 added implementations of DoubleToDecimal and FloatToDecimal that encode directly to Latin1 bytes without any allocations: openjdk/jdk@9d20b58

If this was public API, it could be used pretty easily within UTF8JsonGenerator for some fairly massive performance benefits when serializing large numbers of floating point numbers -- something that's very common with GeoJSON.

@Override
public void writeNumber(double d) throws IOException {
    if (this._outputTail + DoubleToDecimal.MAX_CHARS >= this._outputEnd) {
        this._flushBuffer();
    }
    this._outputTail = DoubleToDecimal.LATIN1.putDecimal(this._outputBuffer, this._outputTail, d);
}

A simple benchmark that tests this change by writing a 10k element float/double array to a null output stream shows that this approach is nearly 3x as fast, even when the relevant internal utility is copied out of the JDK (removing the requirement of --add-opens).

Benchmark                                         (type)        (mode)   Mode  Cnt        Score     Error   Units
WriteFloatingPointArray.write                      FLOAT       VANILLA  thrpt    4     1934.454 ±  84.062   ops/s
WriteFloatingPointArray.write:gc.alloc.rate.norm   FLOAT       VANILLA  thrpt    4   880296.792 ±   0.825    B/op
WriteFloatingPointArray.write                      FLOAT  JACKSON_FAST  thrpt    4     2116.445 ±  52.042   ops/s
WriteFloatingPointArray.write:gc.alloc.rate.norm   FLOAT  JACKSON_FAST  thrpt    4   880263.591 ± 248.715    B/op
WriteFloatingPointArray.write                      FLOAT  JDK_INTERNAL  thrpt    4     3708.587 ± 491.341   ops/s
WriteFloatingPointArray.write:gc.alloc.rate.norm   FLOAT  JDK_INTERNAL  thrpt    4      383.432 ±  12.262    B/op
WriteFloatingPointArray.write                      FLOAT      JDK_COPY  thrpt    4     3623.090 ± 240.293   ops/s
WriteFloatingPointArray.write:gc.alloc.rate.norm   FLOAT      JDK_COPY  thrpt    4      383.387 ±  13.224    B/op
WriteFloatingPointArray.write                     DOUBLE       VANILLA  thrpt    4     1268.260 ±  39.709   ops/s
WriteFloatingPointArray.write:gc.alloc.rate.norm  DOUBLE       VANILLA  thrpt    4  1040193.112 ±   0.036    B/op
WriteFloatingPointArray.write                     DOUBLE  JACKSON_FAST  thrpt    4     1532.169 ± 190.942   ops/s
WriteFloatingPointArray.write:gc.alloc.rate.norm  DOUBLE  JACKSON_FAST  thrpt    4  1040192.921 ±   0.115    B/op
WriteFloatingPointArray.write                     DOUBLE  JDK_INTERNAL  thrpt    4     2788.184 ± 497.046   ops/s
WriteFloatingPointArray.write:gc.alloc.rate.norm  DOUBLE  JDK_INTERNAL  thrpt    4      315.239 ±  35.377    B/op
WriteFloatingPointArray.write                     DOUBLE      JDK_COPY  thrpt    4     2704.880 ± 379.627   ops/s
WriteFloatingPointArray.write:gc.alloc.rate.norm  DOUBLE      JDK_COPY  thrpt    4      315.170 ±  34.143    B/op

Based on these results it seems like it would be valuable to optimize Jackson's copy of *ToDecimal and bring back USE_FAST_DOUBLE_WRITER for modern JDKs? I'm not positive but I don't believe the JDK's implementation of these directly into jackson-core due to licensing, and I suspect relying on --add-opens java.base/jdk.internal.math=ALL-UNNAMED is not a good approach for a general purpose library.

[pjfanning]

I don't think we'll want to do this based on the --add-opens requirement and having to have different code for different Java versions and to try to access non public code.
Maybe a better approach would be try to make Jackson's NumberOutput class pluggable - we could allow users to provide their own implementations that override the Jackson default.
On this last point, you can already achieve this yourself by using ByteBuddy or AOP or some other approach that allows you to replace Jackson code in your JVM with code that you like.

[westinrm]

My question is more if it's worth bringing Jackson's *ToDecimal implementations up to the performance level of the JDK, and un-deprecating USE_FAST_DOUBLE_WRITER.

[plokhotnyuk]

I would recommend to use a more advanced XJB algorithm that reduces 128-bit multiplications to just one

Here are examples of ports of its different versions to Scala-based JSON serializers:

• jsoniter-scala: https://github.com/plokhotnyuk/jsoniter-scala/blob/master/jsoniter-scala-core/jvm-native/src/main/scala/com/github/plokhotnyuk/jsoniter_scala/core/JsonWriter.scala#L2257-L2489
• AVSystem commons: https://github.com/AVSystem/scala-commons/pull/906/changes#diff-33e4ded026ceeb5296257ef02cdae199a921ca1ddf4122ca4fdc0037ba7ed4b0R87-R159

Below are throughput charts of benchmark results for GeoJSON serialization by Scala's JSON parsers (including jackson-module-scala and jsoniter-scala) using different JVMs:

[pjfanning]

Thanks @plokhotnyuk for the pointers. I have used Claude to create #1656. I will benchmark it later in the week and also look to tidy up the code a bit. It is basically a port to Java of your Scala code.

[plokhotnyuk]

Thanks @plokhotnyuk for the pointers. I have used Claude to create #1656. I will benchmark it later in the week and also look to tidy up the code a bit. It is basically a port to Java of your Scala code.

Wow! How fast the innovations could spread these days!

I will be happy to remeasure and publish new results for Jackson-module-scala!

[westinrm]

Benchmark                                               (mode)  (type)   Mode  Cnt        Score     Error   Units
WriteFloatingPointArray.write                          VANILLA   FLOAT  thrpt    4     1909.883 ± 102.870   ops/s
WriteFloatingPointArray.write:gc.alloc.rate.norm       VANILLA   FLOAT  thrpt    4   880296.803 ±   0.808    B/op
WriteFloatingPointArray.write                              JDK   FLOAT  thrpt    4     3919.695 ± 455.580   ops/s
WriteFloatingPointArray.write:gc.alloc.rate.norm           JDK   FLOAT  thrpt    4      383.402 ±  12.350    B/op
WriteFloatingPointArray.write                              XJB   FLOAT  thrpt    4     4654.920 ± 252.931   ops/s
WriteFloatingPointArray.write:gc.alloc.rate.norm           XJB   FLOAT  thrpt    4      383.503 ±  10.292    B/op
WriteFloatingPointArray.write                           PR1657   FLOAT  thrpt    4     3021.776 ±  45.271   ops/s
WriteFloatingPointArray.write:gc.alloc.rate.norm        PR1657   FLOAT  thrpt    4   560383.252 ±  15.721    B/op
WriteFloatingPointArray.write                          VANILLA  DOUBLE  thrpt    4     1248.593 ±  81.114   ops/s
WriteFloatingPointArray.write:gc.alloc.rate.norm       VANILLA  DOUBLE  thrpt    4  1040193.129 ±   0.073    B/op
WriteFloatingPointArray.write                              JDK  DOUBLE  thrpt    4     2992.029 ±  81.325   ops/s
WriteFloatingPointArray.write:gc.alloc.rate.norm           JDK  DOUBLE  thrpt    4      314.905 ±  31.409    B/op
WriteFloatingPointArray.write                              XJB  DOUBLE  thrpt    4     3225.476 ± 122.495   ops/s
WriteFloatingPointArray.write:gc.alloc.rate.norm           XJB  DOUBLE  thrpt    4      312.438 ±   0.037    B/op
WriteFloatingPointArray.write                           PR1657  DOUBLE  thrpt    4     2774.433 ±  44.497   ops/s
WriteFloatingPointArray.write:gc.alloc.rate.norm        PR1657  DOUBLE  thrpt    4   640375.258 ±  98.059    B/op

JDK refers to a copy of the JDK decimal conversions
PR1657 refers to #1657
XJB refers to #1656 (plus the wiring so it's used by UTF8JsonGenerator)

[pjfanning]

@westinrm 1656 and 1657 address different issues and it's quite possible that both will be merged.

I have an overly simplistic benchmark at https://github.com/pjfanning/double-reader-writer and it needs more work. The README has the results. Focuses only on the number writing to string and not on how it integrates with the Jackson JSON Generators. The TLDR so far is that XJB is similar to Schubfach in performance. The public JDK toString has caught up in Java 25.

It's quite possible that my XJB fork is missing something and can be improved on. Even if it can't be improved on, it does have the nice feature of supporting the PR1657 change for Utf8 Json Generator better than the existing schubfach code. @westinrm I have a branch that has a combined 1656 and1657 branch if you are interested in adding that to your benchmark? https://github.com/pjfanning/jackson-core/tree/xjb2

[westinrm]

ah sorry I didn't make it clear -- I included some extra boiler plate with 1656 so it actually gets used by the JsonGenerator. (My benchmark substitutes out the JsonGenerator implementation with ones that have different implementations of writeNumber)

[pjfanning]

3.2.2 was released with a small enhancement that improves generating to a byte stream (but not char stream) and only if StreamWriteFeature.USE_FAST_DOUBLE_WRITER is enabled. The full XJB switch will hopefully land in 3.3.0 and hopefully will also improve the performance for char stream output. StreamWriteFeature.USE_FAST_DOUBLE_WRITER will still need to be enabled.

[pjfanning]

If anyone is reading this and wants to improve the performance of their Jackson based serialization/deserialization, they should consider using Binary formats instead of plain JSON. Writing numbers in binary formats and reading them back like that is much faster than turning them into chars for transmission.

Jackson supports multiple binary formats and there are some externally maintained Jackson compatible libs for other formats.

• https://github.com/fasterxml/jackson-dataformats-binary
• https://github.com/msgpack/msgpack-java/blob/main/msgpack-jackson/README.md
• https://github.com/michel-kraemer/bson4jackson
• probably others