Separate maximum lengths of integer types (BigInteger) and floating-point (BigDecimal) in `StreamReadConstraints

[cowtowncoder]

I know we have gone back and forth with this question, but I think that it would make sense to allow specifying different maximum lengths for integer numbers and floating-point numbers. This is mostly because:

1. Cost of processing floating-point numbers can be significantly higher (and go slow really fast when length grows beyond certain point) than that of integers (at least wrt BigInteger handling) AND
2. There are conceivable cases where lengths for BigInteger may need to exceed anything that makes sense for BigDecimal -- f.ex for cryptographic cases.

Put another way: someone might want to cap FPs to, say, 100 digits, but allow BigIntegers with, say, over 1000 digits.

Now: I think that we might want to leave a convenience method that sets both limits -- Builder.maxNumberLength() -- while introducing new ones. We already have separate validation methods, but would need to separate accessors.

And finally, we could consider changing defaults to be different; although I think default of 1000 is not a bad choice.

[cowtowncoder]

/cc @pjfanning -- Just hoping to nail this one before we do our 2.15 release candidates, sometime in early March (I hope).

[pjfanning]

I am not convinced. BigInteger parsing is just about as slow as BigDecimal parsing.

[cowtowncoder]

I am not convinced. BigInteger parsing is just about as slow as BigDecimal parsing.

Really? Is the parsing of Double then something that is significantly slower (wrt 2- vs 10-base)?

[pjfanning]

BigInteger and BigDecimal are by the far the most dangerous regarding parse times. FasterXML/jackson-module-scala#609 was caused by BigInteger parsing.

[cowtowncoder]

Ok. My understanding on floating-point parsing performance is incorrect then.

I'll close this issue.

[cowtowncoder]

Ok I decided to have a look and you are right in that performance difference b/w BigInteger and BigDecimal is negligible: I guess their internal representations are similar (latter just has the magnitude for "moving" decimal point etc).

About the only interesting finding is that: java.lang.Double decoding is slightly slower yet; in my test: for 1000 digit numbers 50% more time spent.
Test I'll add in https://github.com/cowtowncoder/misc-micro-benchmarks gives:

Benchmark                               Mode  Cnt    Score   Error  Units
LongNumberParsing.perfParseBigDecimal  thrpt    5  662.874 ± 5.964  ops/s
LongNumberParsing.perfParseBigInteger    thrpt   5  671.848 ± 4.698  ops/s
LongNumberParsing.perfParseDouble         thrpt    5  434.849 ± 1.793  ops/s

(but with 200 digits, numbers are same... odd)

So your point stands: performance of plain decoding (never mind use) is very similar for these "big number" cases.