[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