On Tue, 12 Mar 2024 13:07:26 GMT, Shaojin Wen <d...@openjdk.org> wrote:
>> The current BigDecimal(String) constructor calls String#toCharArray, which
>> has a memory allocation.
>>
>>
>> public BigDecimal(String val) {
>> this(val.toCharArray(), 0, val.length()); // allocate char[]
>> }
>>
>>
>> When the length is greater than 18, create a char[]
>>
>>
>> boolean isCompact = (len <= MAX_COMPACT_DIGITS); // 18
>> if (!isCompact) {
>> // ...
>> } else {
>> char[] coeff = new char[len]; // allocate char[]
>> // ...
>> }
>>
>>
>> This PR eliminates the two memory allocations mentioned above, resulting in
>> an approximate 60% increase in performance..
>
> Shaojin Wen has updated the pull request incrementally with one additional
> commit since the last revision:
>
> restore comment
I agree with you, the char[] constructors is probably less performance
sensitive than the others.
The performance numbers under MacBookPro M1 Max are as follows:
-Benchmark Mode Cnt Score Error
Units (one CharArraySequence)
-BigDecimals.testConstructorWithSmallCharArray avgt 15 19.157 ? 0.074 ns/op
+Benchmark Mode Cnt Score Error
Units (two CharArraySequence)
+BigDecimals.testConstructorWithSmallCharArray avgt 15 17.833 ? 0.124
ns/op +7.42
-------------
PR Comment: https://git.openjdk.org/jdk/pull/18177#issuecomment-1991781940
