On Tue, 5 Sep 2023 15:46:17 GMT, 温绍锦 <d...@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
