[jdk17u-dev] RFR: 8304976: Optimize DateTimeFormatterBuilder.ZoneTextPrinterParser.getTree() [v2]

[Aleksey Shipilev]

On Thu, 1 Jun 2023 13:01:31 GMT, Oli Gillespie <ogillespie at openjdk.org> wrote:

>> Hi all,
>> 
>> This pull request contains a backport of commit [438c969b](https://github.com/openjdk/jdk/commit/438c969b7b07eeef0158b089e5a168849e04bf56) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
>> 
>> The commit being backported was authored by Sergey Tsypanov on 29 Mar 2023 and was reviewed by Naoto Sato.
>> 
>> Since the original uses the new `newHashMap` and `newHashSet` methods from https://bugs.openjdk.org/browse/JDK-8284780 which are not here in 17, I've not included those changes in the backport. They are not a significant part of the original fix, the main point of the change is kept which is avoiding the creation of 2 new hash sets on the cached path. Running the included benchmark confirms the performance improvement even with the omissions:
>> 
>> Base:
>> 
>> Benchmark                                                  Mode  Cnt      Score     Error   Units
>> ZonedDateTimeFormatterBenchmark.parse                      avgt   20  18248.082 ? 166.440   ns/op
>> ZonedDateTimeFormatterBenchmark.parse:?gc.alloc.rate       avgt   20   1274.964 ?  11.448  MB/sec
>> ZonedDateTimeFormatterBenchmark.parse:?gc.alloc.rate.norm  avgt   20  24400.418 ?   1.591    B/op
>> ZonedDateTimeFormatterBenchmark.parse:?gc.count            avgt   20     44.000            counts
>> ZonedDateTimeFormatterBenchmark.parse:?gc.time             avgt   20     35.000                ms
>> 
>> 
>> Patch:
>> 
>> Benchmark                                                  Mode  Cnt    Score   Error   Units
>> ZonedDateTimeFormatterBenchmark.parse                      avgt   20  923.943 ? 8.737   ns/op
>> ZonedDateTimeFormatterBenchmark.parse:?gc.alloc.rate       avgt   20  883.450 ? 8.163  MB/sec
>> ZonedDateTimeFormatterBenchmark.parse:?gc.alloc.rate.norm  avgt   20  856.021 ? 0.079    B/op
>> ZonedDateTimeFormatterBenchmark.parse:?gc.count            avgt   20   32.000          counts
>> ZonedDateTimeFormatterBenchmark.parse:?gc.time             avgt   20   27.000              ms
>
> Oli Gillespie has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Set initial capacity for maps

src/java.base/share/classes/java/time/format/DateTimeFormatterBuilder.java line 4200:

> 4198:                 tree = PrefixTree.newTree(context);
> 4199:                 zoneStrings = TimeZoneNameUtility.getZoneStrings(locale);
> 4200:                 Set<String> nonRegionIds = new HashSet<>(64);

Does the same argument about load factor applies here? So it should be not `64`, but something more? Load factor `0.75` implies it should be at least `86`. (The size would be rounded to the next power of two internally, so `128` might as well do.)

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

PR Review Comment: https://git.openjdk.org/jdk17u-dev/pull/1414#discussion_r1214060526