On Tue, 30 Sep 2025 15:35:03 GMT, Johannes Graham wrote:
> This is a followup to https://github.com/openjdk/jdk/pull/27118, to clean up
> resulting unused code.
> - remove `getChars`, `isExceptional` and `isNegative`
> - remove `ExceptionalBinaryToASCIIBuffer`; throws `IllegalArgum
of that.(Caller already asserts
> non-exceptional arg)
Johannes Graham has updated the pull request incrementally with one additional
commit since the last revision:
Update src/java.base/share/classes/jdk/internal/math/FloatingDecimal.java
Co-authored-by: Raffaello Giulietti
-
This is a followup to https://github.com/openjdk/jdk/pull/27118, to clean up
resulting unused code.
- remove `getChars`, `isExceptional` and `isNegative`
- remove `ExceptionalBinaryToASCIIBuffer`; throws `IllegalArgumentException`
instead of returning an instance of that.(Caller already asserts
On Wed, 24 Sep 2025 14:59:05 GMT, Johannes Graham wrote:
>> When formatting doubles or BigDecimals, DigitList first formats them as a
>> string and then parses the resultant string to extract the mantissa and the
>> exponent. This can be done more directly. This allows rem
On Fri, 5 Sep 2025 14:18:19 GMT, Johannes Graham wrote:
> When formatting doubles or BigDecimals, DigitList first formats them as a
> string and then parses the resultant string to extract the mantissa and the
> exponent. This can be done more directly. This allows removing som
On Fri, 12 Sep 2025 22:44:54 GMT, Johannes Graham wrote:
>> When formatting doubles or BigDecimals, DigitList first formats them as a
>> string and then parses the resultant string to extract the mantissa and the
>> exponent. This can be done more directly. This allows rem
On Mon, 8 Sep 2025 02:27:10 GMT, Shaojin Wen wrote:
>> This PR introduces a new efficient API for appending two-digit integers to
>> StringBuilders and refactors DateTimeHelper to leverage this new
>> functionality.
>>
>> Changes include:
>>
>> 1. New `appendPair` method for efficient two-dig
t;
> This also facilitates potential cleanups in FloatingDecimal (removal of
> getChars method) but I've left that for later to minimize conflicts with
> other changes there.
Johannes Graham has updated the pull request incrementally with one additional
commit since the
On Wed, 10 Sep 2025 23:47:47 GMT, Johannes Graham wrote:
>> When formatting doubles or BigDecimals, DigitList first formats them as a
>> string and then parses the resultant string to extract the mantissa and the
>> exponent. This can be done more directly. This allows rem
On Wed, 10 Sep 2025 21:19:32 GMT, Justin Lu wrote:
>> Johannes Graham has updated the pull request incrementally with two
>> additional commits since the last revision:
>>
>> - use Level.Invocation
>> - review fixes
>
> src/java.base/share/classes
On Wed, 10 Sep 2025 21:06:53 GMT, Justin Lu wrote:
>> Johannes Graham has updated the pull request incrementally with two
>> additional commits since the last revision:
>>
>> - use Level.Invocation
>> - review fixes
>
> test/micro/org/openjdk/bench/java/
t;
> This also facilitates potential cleanups in FloatingDecimal (removal of
> getChars method) but I've left that for later to minimize conflicts with
> other changes there.
Johannes Graham has updated the pull request incrementally with two additional
commits since the last revis
On Fri, 5 Sep 2025 14:18:19 GMT, Johannes Graham wrote:
> When formatting doubles or BigDecimals, DigitList first formats them as a
> string and then parses the resultant string to extract the mantissa and the
> exponent. This can be done more directly. This allows removing som
When formatting doubles or BigDecimals, DigitList first formats them as a
string and then parses the resultant string to extract the mantissa and the
exponent. This can be done more directly. This allows removing some parsing
code and removes a cached byte array.
This also facilitates potential
On Fri, 5 Sep 2025 14:56:25 GMT, Raffaello Giulietti
wrote:
> Would you like me to reconsider their removals in my [draft
> PR](https://github.com/openjdk/jdk/pull/26990)?
Yes, please.
-
PR Comment: https://git.openjdk.org/jdk/pull/27118#issuecomment-3258817438
On Wed, 20 Aug 2025 14:39:24 GMT, Shaojin Wen wrote:
>> Since FloatToDecimal and DoubleToDecimal are used in Float.toString and
>> Double.toString, some code in FloatingDecimal is not used.
>>
>> This PR refactors `FloatingDecimal` and `DigitList` to improve efficiency
>> and reduce code dupl
On Wed, 20 Aug 2025 14:39:24 GMT, Shaojin Wen wrote:
>> Since FloatToDecimal and DoubleToDecimal are used in Float.toString and
>> Double.toString, some code in FloatingDecimal is not used.
>>
>> This PR refactors `FloatingDecimal` and `DigitList` to improve efficiency
>> and reduce code dupl
On Sat, 25 Jan 2025 13:04:52 GMT, Shaojin Wen wrote:
> Since FloatToDecimal and DoubleToDecimal are used in Float.toString and
> Double.toString, some code in FloatingDecimal is not used. This refactoring
> is to remove the unused code and reuse DecimalDigits to reduce duplication of
> code.
On Mon, 27 Jan 2025 00:22:42 GMT, Chen Liang wrote:
>> Creating a BinaryToASCIIConverter is not expensive and does not require the
>> use of cache, but this should be proven by performance testing.
>
> Each `BinaryToASCIIBuffer` allocates an array for digits. That might be why
> the buffer was
On Mon, 16 Jun 2025 21:19:45 GMT, Johannes Graham wrote:
>> This PR replaces construction of intermediate strings to be parsed with more
>> direct manipulation of numbers. It also has a more streamlined mechanism of
>> handling `Long.MIN_VALUE` when pars
On Wed, 4 Jun 2025 18:18:39 GMT, Johannes Graham wrote:
> This PR replaces construction of intermediate strings to be parsed with more
> direct manipulation of numbers. It also has a more streamlined mechanism of
> handling `Long.MIN_VALUE` when parsing longs by using `Long.parseUns
ates the use of a cached StringBuilder
> in DigitList.
>
> Testing:
> - GHA
> - Local run of tier 2 and jtreg:jdk/java/text
> - New benchmark: DecimalFormatParseBench
Johannes Graham has updated the pull request incrementally with one additional
commit since t
On Thu, 12 Jun 2025 22:52:21 GMT, Justin Lu wrote:
>> Unfortunately some check is required (a test fails), but I now realize what
>> I had was wrong. The issue is that on line 1084
>> (https://github.com/openjdk/jdk/pull/25644/files#diff-79e6fd549b5ec5e7f49658581beddcb07fcbb0c09ae8e1117c385b665
ates the use of a cached StringBuilder
> in DigitList.
>
> Testing:
> - GHA
> - Local run of tier 2 and jtreg:jdk/java/text
> - New benchmark: DecimalFormatParseBench
Johannes Graham has updated the pull request incrementally with one additional
commit since the last revisi
On Wed, 11 Jun 2025 23:47:01 GMT, Justin Lu wrote:
>> Johannes Graham has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Address review comments
>
> src/java.base/share/classes/jdk/internal/math/FloatingDeci
ates the use of a cached StringBuilder
> in DigitList.
>
> Testing:
> - GHA
> - Local run of tier 2 and jtreg:jdk/java/text
> - New benchmark: DecimalFormatParseBench
Johannes Graham has updated the pull request incrementally with one additional
commit since the las
ates the use of a cached StringBuilder
> in DigitList.
>
> Testing:
> - GHA
> - Local run of tier 2 and jtreg:jdk/java/text
> - New benchmark: DecimalFormatParseBench
Johannes Graham has updated the pull request incrementally with one additional
commit since the last rev
On Mon, 9 Jun 2025 22:08:08 GMT, Naoto Sato wrote:
>> Sorry, I'm not seeing where the original could throw ParseException.
>
> Sorry if I was unclear. I mean the `parse()` in the NumberFormat do not throw
> NumberFormatException/ArithmeticException, but ParseException, so if this
> piece of cod
ates the use of a cached StringBuilder
> in DigitList.
>
> Testing:
> - GHA
> - Local run of tier 2 and jtreg:jdk/java/text
> - New benchmark: DecimalFormatParseBench
Johannes Graham has updated the pull request incrementally with one additional
commit since the last revis
On Mon, 9 Jun 2025 21:45:12 GMT, Naoto Sato wrote:
>> I will leave this question to I18N reviewers, who are ultimately in charge
>> of DigitList.
>
> The existing implementation does not throw
> `NumberFormatException`/`ArithmeticException`, but `ParseException` if
> parsing is failing. I woul
This PR replaces construction of intermediate strings to be parsed with more
direct manipulation of numbers. It also has a more streamlined mechanism of
handling `Long.MIN_VALUE` when parsing longs by using `Long.parseUnsignedLong`
As a small side-effect it also eliminates the use of a cached St
On Wed, 4 Jun 2025 23:15:37 GMT, Chen Liang wrote:
>> This PR replaces construction of intermediate strings to be parsed with more
>> direct manipulation of numbers. It also has a more streamlined mechanism of
>> handling `Long.MIN_VALUE` when parsing longs by using
>> `Long.parseUnsignedLong`
On Wed, 4 Jun 2025 18:18:39 GMT, Johannes Graham wrote:
> This PR replaces construction of intermediate strings to be parsed with more
> direct manipulation of numbers. It also has a more streamlined mechanism of
> handling `Long.MIN_VALUE` when parsing longs by using `Long.parseUns
On Thu, 5 Jun 2025 20:29:48 GMT, Justin Lu wrote:
>> Please review this PR which improves occurrences of lazy computation in
>> `Locale` and `BaseLocale`.
>>
>> Existing lazy initialization strategies such as CHM, static nested class,
>> and local inner class are replaced with Stable Values.
>
On Mon, 19 May 2025 23:53:07 GMT, Shaojin Wen wrote:
>> Improve the performance of UUID::toString by using Long.expand and SWAR
>> (SIMD within a register) instead of table lookup. Eliminating the table
>> lookup can also avoid the performance degradation problem when the cache
>> misses.
>
>
On Mon, 19 May 2025 23:53:07 GMT, Shaojin Wen wrote:
>> Improve the performance of UUID::toString by using Long.expand and SWAR
>> (SIMD within a register) instead of table lookup. Eliminating the table
>> lookup can also avoid the performance degradation problem when the cache
>> misses.
>
>
On Mon, 19 May 2025 23:53:07 GMT, Shaojin Wen wrote:
>> Improve the performance of UUID::toString by using Long.expand and SWAR
>> (SIMD within a register) instead of table lookup. Eliminating the table
>> lookup can also avoid the performance degradation problem when the cache
>> misses.
>
>
On Tue, 20 May 2025 21:53:21 GMT, Shaojin Wen wrote:
>> src/java.base/share/classes/java/util/UUID.java line 528:
>>
>>> 526: *
>>> 527: * Input: 0x0123456789ABCDEF
>>> 528: * Output: 0x3031323334353637 ('0','1','2','3','4','5','6','7' in
>>> ASCII)
>>
>> Only the low 32 bits
On Sun, 11 May 2025 16:22:11 GMT, Johannes Graham wrote:
> Optimize `BigDecimal.valueOf(double)` by using `FormattedFPDecimal` instead
> of converting to decimal string and then parsing it. This results in an
> approximate 6x improvement for me.
This pull request has now been i
On Mon, 12 May 2025 02:06:23 GMT, Chen Liang wrote:
>> Optimize `BigDecimal.valueOf(double)` by using `FormattedFPDecimal` instead
>> of converting to decimal string and then parsing it. This results in an
>> approximate 6x improvement for me.
>
> Sorry, didn't see your core-libs-dev mail. Crea
> Optimize `BigDecimal.valueOf(double)` by using `FormattedFPDecimal` instead
> of converting to decimal string and then parsing it. This results in an
> approximate 6x improvement for me.
Johannes Graham has updated the pull request incrementally with three
additional commits since
> Optimize `BigDecimal.valueOf(double)` by using `FormattedFPDecimal` instead
> of converting to decimal string and then parsing it. This results in an
> approximate 6x improvement for me.
Johannes Graham has updated the pull request incrementally with one additional
commit since
On Wed, 14 May 2025 09:55:35 GMT, Raffaello Giulietti
wrote:
>> Johannes Graham has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> fix code tag in javadoc
>
> src/java.base/share/classes/java/math/BigDeci
> Optimize `BigDecimal.valueOf(double)` by using `FormattedFPDecimal` instead
> of converting to decimal string and then parsing it. This results in an
> approximate 6x improvement for me.
Johannes Graham has updated the pull request incrementally with one additional
commit since
On Sun, 11 May 2025 18:45:47 GMT, Chen Liang wrote:
>> Optimize `BigDecimal.valueOf(double)` by using `FormattedFPDecimal` instead
>> of converting to decimal string and then parsing it. This results in an
>> approximate 6x improvement for me.
>
> test/jdk/java/math/BigDecimal/ValueOfDouble.jav
On Sun, 11 May 2025 16:22:11 GMT, Johannes Graham wrote:
> Optimize `BigDecimal.valueOf(double)` by using `FormattedFPDecimal` instead
> of converting to decimal string and then parsing it. This results in an
> approximate 6x improvement for me.
On Aarch64 M4:
Optimize `BigDecimal.valueOf(double)` by using `FormattedFPDecimal` instead of
converting to decimal string and then parsing it. This results in an
approximate 6x improvement for me.
-
Commit messages:
- add bug number to test, fix typo
- wait for real bug number to set it in head
This is somewhat of followup to a conversation a few months ago [1]
regarding the non-existence of a BigDecimal.valueOf(float) method. While it
wasn't the primary issue, the matter of performance did come up. Based on
that, I have been experimenting with making some improvements there.
I have a d
On Mon, 5 May 2025 17:32:19 GMT, Roger Riggs wrote:
>> Refactor AbstractStringBuilder to maintain consistency among count, coder,
>> and value buffers while the buffer capacity is being expanded and/or
>> inflated from Latin1 to UTF16 representations.
>> The refactoring pattern is to read and
On Tue, 29 Apr 2025 15:10:10 GMT, fabioromano1 wrote:
>> This PR optimizes `BigInteger.pow(int)` method. The primary enhancement in
>> `pow()` is not concerned most on execution time, but rather in memory
>> optimization, because the PR implementation does the "shift of the exponent"
>> squari
On Sat, 26 Apr 2025 21:48:25 GMT, fabioromano1 wrote:
>> This PR optimizes `BigInteger.pow(int)` method. The primary enhancement in
>> `pow()` is not concerned most on execution time, but rather in memory
>> optimization, because the PR implementation does the "shift of the exponent"
>> squari
On Wed, 23 Apr 2025 16:52:29 GMT, Brian Burkhalter wrote:
>> Implement the requested methods and add a test thereof.
>
> Brian Burkhalter has updated the pull request incrementally with one
> additional commit since the last revision:
>
> 8354724: Improve test per reviewer comments
src/java.
On Thu, 17 Apr 2025 16:18:55 GMT, Brian Burkhalter wrote:
> Implement the requested methods and add a test thereof.
test/jdk/java/io/BufferedReader/ReadAll.java line 34:
> 32:
> 33: import java.io.BufferedReader;
> 34: import java.io.File;
Cosmetic thought - I think this could all be done wit
On Thu, 17 Apr 2025 17:28:12 GMT, Johannes Graham wrote:
>> Implement the requested methods and add a test thereof.
>
> test/jdk/java/io/BufferedReader/ReadAll.java line 34:
>
>> 32:
>> 33: import java.io.BufferedReader;
>> 34: import java.io.File;
>
>
On Fri, 11 Apr 2025 17:31:08 GMT, Johannes Graham wrote:
> The `DigitList` class used in `DecimalFormat` does not reset the `data` array
> in its clone method. This can cause interference when clones are used
> concurrently.
This pull request has now been integrated.
Changeset:
On Wed, 16 Apr 2025 17:40:39 GMT, Johannes Graham wrote:
>> The `DigitList` class used in `DecimalFormat` does not reset the `data`
>> array in its clone method. This can cause interference when clones are used
>> concurrently.
>
> Johannes Graham has updated the pu
> The `DigitList` class used in `DecimalFormat` does not reset the `data` array
> in its clone method. This can cause interference when clones are used
> concurrently.
Johannes Graham has updated the pull request incrementally with one additional
commit since the last revisio
> The `DigitList` class used in `DecimalFormat` does not reset the `data` array
> in its clone method. This can cause interference when clones are used
> concurrently.
Johannes Graham has updated the pull request incrementally with one additional
commit since the last revision:
> The `DigitList` class used in `DecimalFormat` does not reset the `data` array
> in its clone method. This can cause interference when clones are used
> concurrently.
Johannes Graham has updated the pull request incrementally with one additional
commit since the last revision:
r
On Tue, 15 Apr 2025 22:21:31 GMT, Johannes Graham wrote:
>> The `DigitList` class used in `DecimalFormat` does not reset the `data`
>> array in its clone method. This can cause interference when clones are used
>> concurrently.
>
> Johannes Graham has updated the pu
> The `DigitList` class used in `DecimalFormat` does not reset the `data` array
> in its clone method. This can cause interference when clones are used
> concurrently.
Johannes Graham has updated the pull request incrementally with one additional
commit since the last revision:
br
On Tue, 15 Apr 2025 21:40:56 GMT, Naoto Sato wrote:
>> It would still need something to indicate that it had failed, as well as a
>> way to signal other threads that they should terminate early. Worth changing
>> to an AtomicBoolean?
>
> Ah, ok then. Thanks.
Ok to leave as is? Or is the Atomic
> The `DigitList` class used in `DecimalFormat` does not reset the `data` array
> in its clone method. This can cause interference when clones are used
> concurrently.
Johannes Graham has updated the pull request incrementally with one additional
commit since the last revision:
On Tue, 15 Apr 2025 21:23:20 GMT, Naoto Sato wrote:
>> Johannes Graham has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Terminate test early on failure
>
> test/jdk/java/text/Format/DecimalFormat/Cl
On Tue, 15 Apr 2025 20:21:40 GMT, Naoto Sato wrote:
>> My thinking was that for a test pass, it would never hit the shortcut
>> anyway, so it’s only an optimization for the failure case, which hopefully
>> won’t happen anymore. Seeing the count of all collisions gives some
>> reassurance that
> The `DigitList` class used in `DecimalFormat` does not reset the `data` array
> in its clone method. This can cause interference when clones are used
> concurrently.
Johannes Graham has updated the pull request incrementally with one additional
commit since the last revision:
On Tue, 15 Apr 2025 19:18:03 GMT, Naoto Sato wrote:
>> For the original reproducer I wanted to be _really_ sure that it failed.
>> I've reduced it to be more reasonable. With the current config it still gets
>> 10-100 mismatches for me. I've limited the number of lines that get logged
>> as we
On Tue, 15 Apr 2025 16:49:57 GMT, Justin Lu wrote:
>> Johannes Graham has updated the pull request incrementally with two
>> additional commits since the last revision:
>>
>> - fix test summary
>> - add test
>
> test/jdk/java/text/Format/DecimalFor
> The `DigitList` class used in `DecimalFormat` does not reset the `data` array
> in its clone method. This can cause interference when clones are used
> concurrently.
Johannes Graham has updated the pull request incrementally with one additional
commit since the last revision:
On Fri, 11 Apr 2025 17:31:08 GMT, Johannes Graham wrote:
> The `DigitList` class used in `DecimalFormat` does not reset the `data` array
> in its clone method. This can cause interference when clones are used
> concurrently.
Reproducing code example:
public class DecimalF
On Tue, 15 Apr 2025 14:43:56 GMT, Johannes Graham wrote:
>> The `DigitList` class used in `DecimalFormat` does not reset the `data`
>> array in its clone method. This can cause interference when clones are used
>> concurrently.
>
> Johannes Graham has updated the pu
> The `DigitList` class used in `DecimalFormat` does not reset the `data` array
> in its clone method. This can cause interference when clones are used
> concurrently.
Johannes Graham has updated the pull request incrementally with two additional
commits since the last revision:
-
The `DigitList` class used in `DecimalFormat` does not reset the `data` array
in its clone method. This can cause interference when clones are used
concurrently.
-
Commit messages:
- reset "data" field in clone
Changes: https://git.openjdk.org/jdk/pull/24598/files
Webrev: https:
There is one form of array builder already in the JDK - Stream.builder().
This doesn't cover off all of the use-cases, but covers some of them
(notably not the byte array case).
-Johannes
On Fri, Apr 11, 2025 at 11:47 AM Archie Cobbs
wrote:
> To try to loop back on my original point...
>
> Th
On Sat, 5 Apr 2025 05:30:25 GMT, Shaojin Wen wrote:
>> Improve the performance of UUID::toString by using Long.expand and SWAR
>> (SIMD within a register) instead of table lookup. Eliminating the table
>> lookup can also avoid the performance degradation problem when the cache
>> misses.
>
> S
On Tue, 25 Mar 2025 15:52:07 GMT, Per Minborg wrote:
>> Implement JEP 502.
>>
>> The PR passes tier1-tier3 tests.
>
> Per Minborg has updated the pull request incrementally with one additional
> commit since the last revision:
>
> Revamp toString() methods
src/java.base/share/classes/jdk/in
On Mon, 6 Jan 2025 13:18:50 GMT, Shaojin Wen wrote:
> Improve the performance of UUID::toString by using Long.expand and SWAR (SIMD
> within a register) instead of table lookup. Eliminating the table lookup can
> also avoid the performance degradation problem when the cache misses.
By stepping
On Sat, 11 Jan 2025 05:21:36 GMT, Shaojin Wen wrote:
>> Improve the performance of UUID::toString by using Long.expand and SWAR
>> (SIMD within a register) instead of table lookup. Eliminating the table
>> lookup can also avoid the performance degradation problem when the cache
>> misses.
>
>
On Tue, 25 Mar 2025 15:52:07 GMT, Per Minborg wrote:
>> Implement JEP 502.
>>
>> The PR passes tier1-tier3 tests.
>
> Per Minborg has updated the pull request incrementally with one additional
> commit since the last revision:
>
> Revamp toString() methods
test/jdk/java/lang/StableValue/Sta
On Tue, 25 Mar 2025 15:52:07 GMT, Per Minborg wrote:
>> Implement JEP 502.
>>
>> The PR passes tier1-tier3 tests.
>
> Per Minborg has updated the pull request incrementally with one additional
> commit since the last revision:
>
> Revamp toString() methods
src/java.base/share/classes/jdk/in
On Tue, 11 Mar 2025 07:48:40 GMT, Per Minborg wrote:
>> src/java.base/share/classes/java/util/ImmutableCollections.java line 772:
>>
>>> 770:
>>> 771: @jdk.internal.ValueBased
>>> 772: static final class StableList extends AbstractImmutableList {
>>
>> Is there significant reuse gained
On Mon, 10 Mar 2025 18:11:23 GMT, Per Minborg wrote:
> Implement JEP 502.
>
> The PR passes tier1-tier3 tests.
src/java.base/share/classes/java/util/ImmutableCollections.java line 772:
> 770:
> 771: @jdk.internal.ValueBased
> 772: static final class StableList extends AbstractImmutabl
On Mon, 10 Mar 2025 23:42:06 GMT, Chen Liang wrote:
>> src/java.base/share/classes/jdk/internal/lang/stable/StableEnumFunction.java
>> line 112:
>>
>>> 110: final Class enumType =
>>> (Class)inputs.iterator().next().getClass();
>>> 111: return (Function) new StableEnumFunction(
On Sat, 1 Feb 2025 08:42:32 GMT, Shaojin Wen wrote:
>> Continue to complete PR #16006 and PR #21593 to improve BigDecimal::toString
>> and BigDecimal::toPlainString performance and reduce duplicate code
>
> Shaojin Wen has updated the pull request with a new target base due to a
> merge or a re
On Thu, 30 Jan 2025 14:20:36 GMT, Shaojin Wen wrote:
>> By removing the redundant code logic in
>> DateTimeFormatterBuilder$InstantPrinterParser#formatTo, the codeSize can be
>> reduced and the performance can be improved.
>
> Shaojin Wen has updated the pull request incrementally with one addi
On Wed, 29 Jan 2025 16:30:46 GMT, Shaojin Wen wrote:
>> This is an optimization for decimal Integer.parseInt and Long.parseLong,
>> which improves performance by about 10%. The optimization includes:
>> 1. Improve performance by parsing 2 numbers at a time, which has performance
>> improvements
On Tue, 28 Jan 2025 01:24:43 GMT, Shaojin Wen wrote:
>> This is an optimization for decimal Integer.parseInt and Long.parseLong,
>> which improves performance by about 10%. The optimization includes:
>> 1. Improve performance by parsing 2 numbers at a time, which has performance
>> improvements
On Mon, 27 Jan 2025 06:03:17 GMT, Shaojin Wen wrote:
>> src/java.base/share/classes/java/math/BigDecimal.java line 3538:
>>
>>> 3536: return (signum < 0 ? "-0." : "0.").concat(intString);
>>> 3537: } else if (insertionPoint > 0) { /* Point goes inside intVal
>>> */
>>> 3538:
On Sat, 25 Jan 2025 07:25:40 GMT, Shaojin Wen wrote:
> Continue to complete PR #16006 and PR #21593 to improve BigDecimal::toString
> and BigDecimal::toPlainString performance and reduce duplicate code
src/java.base/share/classes/java/math/BigDecimal.java line 3538:
> 3536: return
89 matches
Mail list logo
