<i18n dev> RFR: 8333462: Performance regression of new DecimalFormat() when compare to jdk11

[Justin Lu]

On Tue, 4 Jun 2024 02:32:28 GMT, lingjun-cg <duke at openjdk.org> wrote:

> Run the below benchmark test  ,it show the average time of new DecimalFormat()  increase 18% when compare to jdk 11.
> 
> the result with jdk 11:
> 
> Benchmark                          Mode  Cnt    Score   Error  Units
> JmhDecimalFormat.testNewOnly       avgt   50  248.300 ? 5.158  ns/op
> 
> 
> the result with current jdk:
> 
> Benchmark                          Mode  Cnt    Score   Error  Units
> JmhDecimalFormat.testNewOnly       avgt   50  303.381 ? 5.252  ns/op
> 
> 
> 
> @BenchmarkMode(Mode.AverageTime)
> @Warmup(iterations = 5, time = 500, timeUnit = TimeUnit.MILLISECONDS)
> @Measurement(iterations = 10, time = 500, timeUnit = TimeUnit.MILLISECONDS)
> @State(Scope.Thread)
> @OutputTimeUnit(TimeUnit.NANOSECONDS)
> public class JmhDecimalFormat {
> 
>     @Setup(Level.Trial)
>     public void setup() {
>     }
> 
>     @Benchmark
>     public void testNewOnly() throws InterruptedException {
>         new DecimalFormat("#0.00000");
>     }
> }
> 
> 
> Compare the flame graph it shows the java.text.DecimalFormatSymbols#findNonFormatChar takes a significant time. 
> After replacing  the lambda implementation with a simple loop , it shows nearly the same performance as jdk 11.
> 
> 
> Benchmark                          Mode  Cnt    Score   Error  Units
> JmhDecimalFormat.testNewOnly       avgt   50  209.874 ? 9.951  ns/op
> 
> 
> [flame-graph-jdk11-jdk21.zip](https://github.com/user-attachments/files/15541764/flame-graph-jdk11-jdk21.zip)

LGTM. Also needs copyright year update

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

Marked as reviewed by jlu (Committer).

PR Review: https://git.openjdk.org/jdk/pull/19534#pullrequestreview-2097304072