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

Aleksey Shipilev shade at openjdk.org
Fri Jun 2 09:51:28 UTC 2023


On Fri, 2 Jun 2023 09:46:12 GMT, Oli Gillespie <ogillespie at openjdk.org> wrote:

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

Right. Actually, scratch my comment, since the current version matches what mainline does.

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

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


More information about the jdk-updates-dev mailing list