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

[Shaojin Wen]

On Wed, 11 Oct 2023 22:10:45 GMT, Shaojin Wen <duke at openjdk.org> wrote:

>> src/java.base/share/classes/java/math/BigDecimal.java line 4168:
>> 
>>> 4166:             int lowInt = (int)intCompact % 100;
>>> 4167:             int highInt = (int)intCompact / 100;
>>> 4168:             int highIntSize = JLA.stringSize(highInt);
>> 
>> Which micros cover performance of this branch?
>> 
>> What performance would you get if you simplified this to, say, `return highInt + (lowInt < 10 ? ".0" : ".") + lowInt;`?
>> 
>> `lowInt` is currently unused since you use `(int) intCompact - highInt * 100` instead below. (While a clever optimization in theory, I believe the JIT should handle a pair of integer modulo and division operations (`a = intValue % 100; b = intValue / 100`) so that it only has to do one division, so please measure that whatever you do here has a significant benefit).
>
> Performance numbers run on MacBook M1 Max:
> 
> -Benchmark                                 Mode  Cnt     Score    Error  Units
> -BigDecimals.testHugeToEngineeringString   avgt   15   217.619 ?  4.617  ns/op
> -BigDecimals.testLargeToEngineeringString  avgt   15    65.183 ?  4.368  ns/op
> -BigDecimals.testSmallToEngineeringString  avgt   15    17.084 ?  0.056  ns/op
> -BigDecimals.testToEngineeringString       avgt   15  1856.849 ? 63.571  ns/op
> 
> +Benchmark                                 Mode  Cnt     Score    Error  Units (eec631c)
> +BigDecimals.testHugeToEngineeringString   avgt   15   164.910 ?  1.514  ns/op (+31.97)
> +BigDecimals.testLargeToEngineeringString  avgt   15    20.826 ?  0.066  ns/op (+212.99)
> +BigDecimals.testSmallToEngineeringString  avgt   15    11.987 ?  0.080  ns/op (+42.53)
> +BigDecimals.testToEngineeringString       avgt   15  1854.372 ? 63.810  ns/op (+0.14)
> 
> 
> The microben covered by fast-path is BigDecimals.testSmallToEngineeringString, highInt + (lowInt < 10 ? ".0" : ".") + lowInt is actually implemented based on StringBuilder and will be much slower than the current baseline.
> 
> Benchmark                                 Mode  Cnt   Score   Error  Units (use StringConcat)
> BigDecimals.testSmallToEngineeringString  avgt   15  41.876 ? 0.182  ns/op

I tested it again and found that the remainder is not slow. This was my wrong impression. I have changed it according to your suggestion.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16006#discussion_r1355834888