RFR: 8327791: Optimization for new BigDecimal(String) [v2]
Chen Liang
liach at openjdk.org
Mon Mar 11 16:49:56 UTC 2024
On Mon, 11 Mar 2024 13:54:06 GMT, Shaojin Wen <duke at 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:
>
> fix code style
In case you've missed, wenshao observed a significant performance drop in https://github.com/openjdk/jdk/pull/18177#issuecomment-1987601447 in which the throughput decreased by 27%. So he decided to keep split code paths for JIT as the char[] path is used as an optimized path in user code, such as in mysql connector.
I personally wonder how profile pollution + lack of escape analysis (CharBuffer wrapper) causes such a significant overhead, maybe there's some unintended optimization in the benchmarks (recall a previous array comparison benchmark without polymorphism) that produced such results.
-------------
PR Comment: https://git.openjdk.org/jdk/pull/18177#issuecomment-1988933531
More information about the core-libs-dev
mailing list