On Sun, 10 Mar 2024 16:11:12 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..
The performance numbers under MacBookPro M1 Max are as follows:
-Benchmark Mode Cnt Score Error Units
(master)
-BigDecimals.testConstructorWithString avgt 15 66.005 ? 0.733 ns/op
+Benchmark Mode Cnt Score Error Units
(current version #aaf04f6)
+BigDecimals.testConstructorWithString avgt 15 39.720 ? 0.266 ns/op +66.17%
Compared to directly using a char[], using CharBuffer.wrap leads to a 27%
decrease in performance.
The performance numbers under MacBookPro M1 Max are as follows:
Benchmark Mode Cnt Score Error Units
(char[] direct)
BigDecimals.testConstructorWithCharArray avgt 15 41.998 ? 0.259 ns/op
Benchmark Mode Cnt Score Error Units
(CharBuffer.wrap)
BigDecimals.testConstructorWithCharArray avgt 15 53.533 ? 1.297 ns/op
-27.46%
Now, new BigDecimal(char[]) and new BigDecimal(String) are using the same
algorithm.
They are two separate paths, and both have seen performance improvements.
The performance numbers under MacBookPro M1 Max are as follows:
-Benchmark Mode Cnt Score Error Units
(master)
-BigDecimals.testConstructorWithCharArray avgt 15 48.448 ? 1.879 ns/op
-BigDecimals.testConstructorWithString avgt 15 65.203 ? 3.871 ns/op
+Benchmark Mode Cnt Score Error Units
（current #)
+BigDecimals.testConstructorWithCharArray avgt 15 41.166 ? 0.940 ns/op
+17.68%
+BigDecimals.testConstructorWithString avgt 15 39.289 ? 0.159 ns/op
+65.95%
-------------
PR Comment: https://git.openjdk.org/jdk/pull/18177#issuecomment-1987283721
PR Comment: https://git.openjdk.org/jdk/pull/18177#issuecomment-1987601447
PR Comment: https://git.openjdk.org/jdk/pull/18177#issuecomment-1988185886
