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

[温绍锦]

On Sun, 24 Sep 2023 11:59:51 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:
> 
>   refactor and cache single conversion FormatSpecifier

> Please don't pile on new refactorings and improvements on a PR that has been opened for review. Better to let things brew as a draft for a bit if you're not sure you're done before opening the PR for review, then once it's been opened (like this one) consider preparing follow-up PR instead of refactoring as you go.
> 
> Specifically I'm not sure [0d977b2](https://github.com/openjdk/jdk/commit/0d977b2febe455f4535e6ee2cb19d3b168d764e3) is a good idea and would like you to roll those changes back. Object pooling for trivial, short-lived objects are considered an anti-pattern, as they add references to old GC generations and share many of the same drawbacks as lookup tables, such as increased cache traffic. Showing great wins on microbenchmarks while being a wash or even regressing real applications.

Sorry, I will pay attention to it in the future and modify it in the open review code. I have revert commit to #0d977b2. I agree with your view on the performance issues of old reference.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15776#issuecomment-1732567054