RFR: 8316704: Regex-free parsing of Formatter and FormatProcessor specifiers

[Claes Redestad]

On Sun, 17 Sep 2023 16:01:33 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)

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