<i18n dev> RFR: 8335791: Speed ​​up j.u.Formatter & String.format [v4]

Shaojin Wen duke at openjdk.org
Fri Jul 19 23:09:31 UTC 2024


On Sat, 6 Jul 2024 00:15:04 GMT, Shaojin Wen <duke at 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 incrementally with one additional commit since the last revision:
> 
>   Implementing JavaUtilFormatterAccess using anonymous class

This PR has a lot of changes, which is a lot of work for review, but it can significantly improve the performance of most String.format scenarios. String.format is widely used, so it is meaningful.

Can someone help me review and finish it? Thanks

@cl4es @liach

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

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


More information about the i18n-dev mailing list