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

[Oli Gillespie]

On Fri, 2 Jun 2023 08:07:52 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> 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.)

It's not clear why 64 was chosen here. Reading https://bugs.openjdk.org/browse/JDK-8235238 I don't see anything which particularly justifies 64. On my system:


Set<String> regionIds = ZoneRulesProvider.getAvailableZoneIds();
Set<String> nonRegionIds = new HashSet<>();
for (String[] z : TimeZoneNameUtility.getZoneStrings(Locale.getDefault())) {
    if (!regionIds.contains(z[0])) nonRegionIds.add(z[0]);
}
System.out.println(nonRegionIds.size());


gives 28, so it seems 64 already accounts for load factor nicely at least on my system.

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

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