On Mon, 3 Jan 2022 19:37:03 GMT, Naoto Sato <na...@openjdk.org> wrote:
>> The proposed fix is to address the performance degradation caused by the fix >> to JDK-8275721. Some amount of the degradation cannot be avoided as the >> lookup now falls back up to the bundles at Locale.ROOT. However, by lowering >> the fallback priority of `regionFormatFallback` than `COMPAT`'s lookup, it >> can avoid the excess bundle lookups for regions. >> I also changed the test case `TestZoneTextPrinterParser.java`, which >> currently iterates over 3 nested loops, i.e., all-locales x all-timezones x >> 8, which is absolutely unnecessary. Made it to sample some locales. >> In addition, I added a microbenchmark for the >> DateFormatSymbols.getZoneStrings() method. Here is the result: >> >> Before the fix to JDK-8275721: >> >> Benchmark Mode Cnt Score Error Units >> ZoneStrings.testZoneStrings ss 5 6.865 ± 0.696 s/op >> >> Before the proposed fix: >> >> Benchmark Mode Cnt Score Error Units >> ZoneStrings.testZoneStrings ss 5 15.741 ± 4.300 s/op >> >> After the proposed fix: >> >> Benchmark Mode Cnt Score Error Units >> ZoneStrings.testZoneStrings ss 5 9.756 ± 3.685 s/op > > Naoto Sato 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 four additional commits since > the last revision: > > - Merge branch 'master' into JDK-8278434 > - Copyright year update > - Added a microbenchmark for zone strings > - 8278434: timeouts in test > java/time/test/java/time/format/TestZoneTextPrinterParser.java Marked as reviewed by joehw (Reviewer). It’s nice to see you’ve got most of the performance back. Hope looping through Zone strings isn't really necessary. ------------- PR: https://git.openjdk.java.net/jdk/pull/6790
