<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