On Fri, 5 Jul 2024 20:43:51 GMT, Shaojin Wen <d...@openjdk.org> wrote:

>> String.format is widely used, and improving its performance is very 
>> meaningful. This PR can significantly improve the performance of 
>> String.format. Sorry, there are many changes, which will take a lot of time. 
>> I hope you can review it patiently.
>> 
>> 
>> Improved performance includes the following:
>> 
>> ## 1. Write directly during the parse process to reduce object allocation.
>> 
>> In the current Formatter implementation, some objects do not need to be 
>> allocated, such as:
>> 
>> 
>> class Formatter {
>>     public Formatter format(Locale l, String format, Object ... args) {
>>      List<FormatString> fsa = parse(format);
>>      // ...
>>     }
>> 
>>     static List<FormatString> parse(String s) {
>>      ArrayList<FormatString> al = new ArrayList<>();
>> 
>>         while (i < max) {
>>             int n = s.indexOf('%', i);
>>             if (n < 0) {
>>                 // 
>>                 al.add(new FixedString(s, i, max));
>>             }
>>         }
>>     }
>> }
>> 
>> In the process of parsing, the content that is not a Specifier is directly 
>> appended without going through FixedString. By directly printing the parsed 
>> FormatString object, there is no need to construct a `List<FormatString> 
>> fsa` to store it.
>> 
>> ## 2. Fast path print
>> Use specialized FormatString implementations for single-character and 
>> single-width specifiers to avoid calling the large FormatSpecifier#print 
>> method.
>> 
>> ## 3. String.format directly calls j.u.Formatter
>> String.format directly calls j.u.Formatter via SharedSecrets to improve 
>> performance
>
> Shaojin Wen has updated the pull request with a new target base due to a 
> merge or a rebase. The incremental webrev excludes the unrelated changes 
> brought in by the merge/rebase. The pull request contains six additional 
> commits since the last revision:
> 
>  - Merge remote-tracking branch 'upstream/master' into optim_str_format_202407
>  - use unknownFormatConversion method construct 
> UnknownFormatConversionException
>  - uppercase static final field name & code format
>  - add stable annotation
>  - replace cast to pattern matching
>  - speed up j.u.Formatter & String.format

About `decimalFormat` performance drop: can you add the 
`@CompilerControl(CompilerControl.Mode.DONT_INLINE)` annotation on the 
benchmark class (or the methods), and show the performance results before and 
after? You can run the test selection as `StringFormat.(complex|decimal)Format` 
to just run the 2 tests with regressions.

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

PR Comment: https://git.openjdk.org/jdk/pull/20055#issuecomment-2211394922

Reply via email to