<i18n dev> RFR: 8358880: Performance of parsing with DecimalFormat can be improved [v3]
Justin Lu
jlu at openjdk.org
Wed Jun 11 23:54:30 UTC 2025
On Tue, 10 Jun 2025 15:41:47 GMT, Johannes Graham <duke at openjdk.org> 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`
>>
>> As a small side-effect it also eliminates 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 revision:
>
> Address review comments
On our CI, I did a java_text JCK run as well as tiers 1-3 on all platforms which both came back good. I just have a final comment.
src/java.base/share/classes/jdk/internal/math/FloatingDecimal.java line 1841:
> 1839:
> 1840: static ASCIIToBinaryConverter readDoubleSignlessDigits(int decExp, char[] digits, int length) {
> 1841: if (decExp < MIN_DECIMAL_EXPONENT) {
Is this check needed? I think `ASCIIToBinaryConverter` will return the proper zero value when `doubleValue()` is invoked.
if (decExponent < MIN_DECIMAL_EXPONENT - 1) {
return (isNegative) ? -0.0 : 0.0;
And if this explicit check is a shortcut, I don't think we would need one for an edge case.
-------------
PR Review: https://git.openjdk.org/jdk/pull/25644#pullrequestreview-2918990809
PR Review Comment: https://git.openjdk.org/jdk/pull/25644#discussion_r2141274926
More information about the i18n-dev
mailing list