RFR: 8315585: Optimization for decimal to string [v3]

[Claes Redestad]

On Tue, 5 Sep 2023 15:46:17 GMT, 温绍锦 <duke at openjdk.org> wrote:

>> BigDecimal is a commonly used class in business development, It is often necessary to perform toString or toPlainString operations on BigDecimal.
>> 
>> The current version uses StringBuilder resulting in multiple memory allocations, I made a modification to improve performance.
>> 
>> Because BigDecimal uses stringCache to cache the result of toString, the performance of toString needs special treatment before testing, such as clearing stringCache by unsafe operation before each test, The performance of toString is similar to that of toEngineering.
>> 
>> The performance data is as follows: 
>> 
>> ## 1. benchmark script
>> 
>> sh make/devkit/createJMHBundle.sh
>> bash configure --with-jmh=build/jmh/jars
>> make test TEST="micro:java.math.BigDecimals.*ToPlainString"
>> make test TEST="micro:java.math.BigDecimals.*ToEngineering"
>> 
>> 
>> ## 2. benchmark environment
>> * virtual machine : [aliyun_ecs_c8i.xlarge](https://help.aliyun.com/zh/ecs/user-guide/overview-of-instance-families#c8i)
>> * cpu intel xeon sapphire rapids (x64)
>> 
>> ## 3. benchmark result
>> 
>> -BigDecimals.testHugeToPlainString         avgt   15   188.691 ±  0.822  ns/op  (baseline)
>> -BigDecimals.testLargeToPlainString        avgt   15    36.656 ±  0.065  ns/op
>> -BigDecimals.testSmallToPlainString        avgt   15    34.342 ±  0.068  ns/op
>> -BigDecimals.testToPlainString             avgt   15  1719.494 ± 24.886  ns/op
>> 
>> +Benchmark                                 Mode  Cnt     Score    Error  Units (optimize)
>> +BigDecimals.testHugeToPlainString         avgt   15   133.972 ?  0.328  ns/op (+40.84%)
>> +BigDecimals.testLargeToPlainString        avgt   15    14.957 ?  0.047  ns/op (145.07%)
>> +BigDecimals.testSmallToPlainString        avgt   15    12.045 ?  0.036  ns/op (+185.11)
>> +BigDecimals.testToPlainString             avgt   15  1643.500 ?  3.217  ns/op (+4.62%)
>> 
>> -Benchmark                                 Mode  Cnt     Score    Error  Units (baseline)
>> -BigDecimals.testHugeToEngineeringString   avgt   15   207.621 ±  5.018  ns/op
>> -BigDecimals.testLargeToEngineeringString  avgt   15    35.658 ±  3.144  ns/op
>> -BigDecimals.testSmallToEngineeringString  avgt   15    15.142 ±  0.053  ns/op
>> -BigDecimals.testToEngineeringString       avgt   15  1813.959 ± 12.842  ns/op
>> 
>> +Benchmark                                 Mode  Cnt     Score    Error  Units (optimize)
>> +BigDecimals.testHugeToEngineeringString   avgt   15   142.110 ?  0.987  ns/op (+45.09%)
>> +BigDecimals.testLargeToEngineeringStr...
>
> 温绍锦 has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:
> 
>  - Merge branch 'master' into optimization_for_decimal_to_string
>  - BigInteger use a separate jla
>  - update copyright info
>  - optimization for decimal to string

I think there is way too much duplication of logic going on here, primarily with `StringLatin1.getChars(long, int, byte[])` (assuming #14699 is accepted in the current state where `Integer.getChars(int, int, byte[])` and `Long.getChars(...)` is moved there). Perhaps the bulk of this could be moved to `StringLatin1` and then exposed via e.g. `JavaLangAccess`.

On the motivation side I think it'd be helpful if you could point to some larger benchmarks, frameworks et.c. where optimizing `BigDecimal::toString` makes a significant difference. There has been some recent optimizations that remove the need for `BigDecimal::toString` for some code paths, e.g., #9410 - does this alleviate the need for this optimization or is this still useful or even critical?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15555#issuecomment-1707087366