RFR: 8316704: Regex-free parsing of Formatter and FormatProcessor specifiers [v7]
Claes Redestad
redestad at openjdk.org
Mon Sep 25 12:49:22 UTC 2023
On Sun, 24 Sep 2023 20:27:53 GMT, 温绍锦 <duke at openjdk.org> wrote:
>> @cl4es made performance optimizations for the simple specifiers of String.format in PR https://github.com/openjdk/jdk/pull/2830. Based on the same idea, I continued to make improvements. I made patterns like %2d %02d also be optimized.
>>
>> The following are the test results based on MacBookPro M1 Pro:
>>
>>
>> -Benchmark Mode Cnt Score Error Units
>> -StringFormat.complexFormat avgt 15 1862.233 ? 217.479 ns/op
>> -StringFormat.int02Format avgt 15 312.491 ? 26.021 ns/op
>> -StringFormat.intFormat avgt 15 84.432 ? 4.145 ns/op
>> -StringFormat.longFormat avgt 15 87.330 ? 6.111 ns/op
>> -StringFormat.stringFormat avgt 15 63.985 ? 11.366 ns/op
>> -StringFormat.stringIntFormat avgt 15 87.422 ? 0.147 ns/op
>> -StringFormat.widthStringFormat avgt 15 250.740 ? 32.639 ns/op
>> -StringFormat.widthStringIntFormat avgt 15 312.474 ? 16.309 ns/op
>>
>> +Benchmark Mode Cnt Score Error Units
>> +StringFormat.complexFormat avgt 15 740.626 ? 66.671 ns/op (+151.45)
>> +StringFormat.int02Format avgt 15 131.049 ? 0.432 ns/op (+138.46)
>> +StringFormat.intFormat avgt 15 67.229 ? 4.155 ns/op (+25.59)
>> +StringFormat.longFormat avgt 15 66.444 ? 0.614 ns/op (+31.44)
>> +StringFormat.stringFormat avgt 15 62.619 ? 4.652 ns/op (+2.19)
>> +StringFormat.stringIntFormat avgt 15 89.606 ? 13.966 ns/op (-2.44)
>> +StringFormat.widthStringFormat avgt 15 52.462 ? 15.649 ns/op (+377.95)
>> +StringFormat.widthStringIntFormat avgt 15 101.814 ? 3.147 ns/op (+206.91)
>
> 温绍锦 has updated the pull request incrementally with one additional commit since the last revision:
>
> fix logic error
src/java.base/share/classes/java/util/Formatter.java line 2944:
> 2942: ++off;
> 2943: argSize = size + 1;
> 2944: size = 0;
pointless `size = 0`
src/java.base/share/classes/java/util/Formatter.java line 2949:
> 2947: }
> 2948: } else {
> 2949: if (first == '0') {
While it's clever to avoid re-parsing I think it muddies the control flow. It would be simpler if we always reset to `off = start; c = first` in this `else` block then unconditionally call `parseFlags(); parseWidth();` outside in `parse`. The few extra calls to `s.charAt(..)` this might add a little overhead on some tests, but the JIT might like the brevity and less branchy structure overall and on larger benchmarks.. Maybe worth experimenting with.
src/java.base/share/classes/java/util/Formatter.java line 2964:
> 2962: widthSize = size;
> 2963: }
> 2964: size = 0;
Pointless `size = 0`
src/java.base/share/classes/java/util/Formatter.java line 2977:
> 2975: if (!Flags.isFlag(c)) {
> 2976: flagSize = size;
> 2977: size = 0;
pointless `size = 0`
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/15776#discussion_r1335806486
PR Review Comment: https://git.openjdk.org/jdk/pull/15776#discussion_r1335817101
PR Review Comment: https://git.openjdk.org/jdk/pull/15776#discussion_r1335817800
PR Review Comment: https://git.openjdk.org/jdk/pull/15776#discussion_r1335779111
More information about the core-libs-dev
mailing list