On Sun, 17 Sep 2023 16:01:33 GMT, 温绍锦 <d...@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) It might be reasonable to add a few more common patterns to the `FormatSpecifier` fast-path, but where to draw the line? FWIW the intent of micros like `complex` and `widthString` wasn't necessarily to invite further optimizations, but to explore the cost of failure, i.e., make sure that the fast-path doesn't add a substantial cost when it doesn't help or only helps somewhat. Since you now specialize for most of the patterns in the micros I think you need to explore some variants that you _don't_ optimize for, such as `"%10.3f"`. Orthogonal optimizations like the `FormatSpecifier` fast-path extension and the `print` fast-path should generally be separate PRs. I was worried this would sprawl out more, but perhaps ~230 lines of code is a reasonable extra weight to make the long tail of `String.format`'s regex-free. I was going to comment that the flag parsing was broken in f303f29 but it seems that it was fixed in the latest. I think we need to make a review pass over all existing tests to make sure all imaginable variants are covered. The parser code also ought to be shared between `Formatter` and `FormatProcessor` so that there's a single source of truth going forward. I think it makes sense to file an RFE and do a full review of this. "Regex-free parsing of Formatter and FormatProcessor specifiers"? 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" ------------- PR Review: https://git.openjdk.org/jdk/pull/15776#pullrequestreview-1630133740 PR Comment: https://git.openjdk.org/jdk/pull/15776#issuecomment-1728424181 PR Comment: https://git.openjdk.org/jdk/pull/15776#issuecomment-1730173405 PR Review Comment: https://git.openjdk.org/jdk/pull/15776#discussion_r1328152682
