performance: don't parse all numbers as BigDecimal

[pjfanning]

JsNumber wraps a BigDecimal. Parsing BigDecimals is expensive. Converting BigDecimals to other number formats later on is expensive - especially to BigInteger (some edge cases have terrible performance).

For me, the ideal is that if you are binding to case class that needs the number as a Long that you parse the number as a Long and not as BigDecimal that later is converted to a Long.

It would need to go into a major version release but I think it would be worth considering having play-json parser create JsNumbers or a new JsLazyNumber that starts with the number in string format avoiding the number parsing overhead early on. The Reads code would parse the Longs/Ints/BigDecimals/etc/ from the String representation of the number.

It's possible that some numbers that are in the JSON input may not be needed when binding to an object instance - so the number won't have to be parsed at all.

Reading

• https://github.com/wrandelshofer/FastDoubleParser
• https://plokhotnyuk.github.io/jsoniter-scala/ (shows play-json a bit behind in perf)

Is the thinking that play-json-jsoniter is the best way to improve performance? I think that play-json-jsoniter can also benefit from avoiding BigDecimals where they are not needed.

[plokhotnyuk]

A better option would be using smithy4play then all routes, data structures, codecs (that will use jsoniter-scala under the hood, see smithy4sJson labeled results here) and API docs for all that will be automatically generated from service definitions written in Smithy IDL. If you will share your definitions with users of your API then they can reuse them for generation of clients even in TypeScript.