On Mon, 25 Sep 2023 12:28:06 GMT, Claes Redestad <redes...@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) > > 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. Good idea. In addition, I also plan to simplify the writing of the for statement, such as: for (int size = 0; off < max; ++off, c = s.charAt(off), size++) { ==> for (int size = 0; off < max; c = s.charAt(++off), size++) { > src/java.base/share/classes/java/util/Formatter.java line 3420: > >> 3418: && fmt.a instanceof StringBuilder sb >> 3419: ) { >> 3420: sb.append(value); > > There's a lot of `if`s here, and this doesn't take into account locales with > non-ASCII digits: > > Locale ar = new Locale.Builder().setLanguageTag("ar-SA-u-nu-arab").build(); > Locale.setDefault(ar); > System.out.println("%d".formatted(10000)); // should print "١٠٠٠٠" but prints > "10000" The change code of print fast-path has been deleted, and parse fast-path has added support for the pattern "%8.3f". Where to draw the line of parse fast-path? I have seen patterns that cause performance problems, and they can be easily implemented, so I added them. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15776#discussion_r1335909991 PR Review Comment: https://git.openjdk.org/jdk/pull/15776#discussion_r1328178751
