Avoid copy when parsing BigDecimal

[marschall]

Avoid a char[] copy when parsing a BigDecimal reducing intermediate
allocation.

[marschall]

While profiling some Jackson code I noted that in order to create a BigDecimal we create a copy of the char[]. There is no need for this, BigDecimal has a char[],int,int constructor since Java 5. In the following micro benchmark I get about 20% throughput improvement.

@OutputTimeUnit(TimeUnit.SECONDS)
public class JacksonStdBigDecimalReadVanilla
{

    private static final JsonFactory JSON_FACTORY = new JsonFactory();
    
    private static final String JSON;

    static {
        StringBuilder json = new StringBuilder();
        json.append('[');
        for (int i = 0; i < 1_000; i++) {
            if (i > 0) {
                json.append(',');
            }
            json.append("123.456");
        }
        json.append(']');
        JSON = json.toString();
    }

    @Benchmark
    public void parseBigDecimal(Blackhole blackhole) throws IOException {
        try (JsonParser parser = JSON_FACTORY.createParser(JSON)) {
            parser.nextToken(); // start array
            
            JsonToken nextToken = parser.nextToken();
            while (nextToken == JsonToken.VALUE_NUMBER_FLOAT) {
                blackhole.consume(parser.getDecimalValue());
                nextToken = parser.nextToken();
            }
        }
    }

}

[cowtowncoder]

Thank you for contributing this patch @marschall -- interesting that we had overlooked existing of that constructor, good catch! I'd be happy to merge this, and the only thing I need (if not already done earlier) is to get CLA from:

https://github.com/FasterXML/jackson/blob/master/contributor-agreement.pdf

it's only needed once before the first Jackson contribution, good for all future contributions (hence if you have sent one earlier LMK and I can verify).
The usual way is to print, fill & sign, scan/photo, email to info at fasterxml dot com.
Once I get that, I'll merge this and it gets into upcoming 2.14.0.

Thank you again very much for providing this -- performance improvements are always welcome!

[marschall]

@cowtowncoder awesome, give me one or two days

[marschall]

@cowtowncoder I sent the CLA, let me know if you need anything more. Should I also submit a PR against FasterXML/jackson-benchmarks?

[cowtowncoder]

CLA recieved, will merge.

[pjfanning]

Would it make more sense to avoid this Arrays.copyOfRange and change the BigDecimalParser constructor to take (chars, off, len)? It looks like the parseBigDecimal can be readily changed to support an offset and explicit len.

[pjfanning]

I have a PR for this

[cowtowncoder]

That could make sense if easy enough to do.

[pjfanning]

#801

[cowtowncoder]

@marschall Merged. As to jackson-benchmarks not sure; this might be little bit too specific to be tested.