JDK-8066291 : ZoneIdPrinterParser can be optimized
  • Type: Bug
  • Component: core-libs
  • Sub-Component: java.time
  • Affected Version: 8
  • Priority: P4
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2014-12-01
  • Updated: 2017-05-17
  • Resolved: 2016-11-21
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 9
9 b147Fixed
Sub Tasks
JDK-8169250 :  
Description
Every time you parse a ZonedDateTime that contains a zone id the method ZoneRulesProvider.getAvailableZoneIds() is called in the ZoneIdPrinterParser.

This method can be very costly. Since there is already a cache to avoid to recreate the SubstringTree it should be possible
to call the ZoneRulesProvider.getAvailableZoneIds() method only when this cache is updated.

For example something like

Set regionIds = cachedRegionIds;
final int regionIdsSize = ZoneRulesProvider.getAvailableZoneIdsSize(); // Return only the size of ZONES in ZoneRulesProvider
Entry cached = cachedSubstringTree;
if (cached == null || cached.getKey() != regionIdsSize) {
cachedRegionIds = ZoneRulesProvider.getAvailableZoneIds();
...

Instead of

Set regionIds = ZoneRulesProvider.getAvailableZoneIds();
final int regionIdsSize = regionIds.size();
Entry cached = cachedSubstringTree;
if (cached == null || cached.getKey() != regionIdsSize) {
...



Originally proposed as https://github.com/ThreeTen/threeten/issues/350

Comments
http://mail.openjdk.java.net/pipermail/core-libs-dev/2016-May/040842.html
11-05-2016

The method has "@return a modifiable copy of the set of zone IDs, not null" Changing from modifiable to immutable is incompatible. I personally have no problem with making that change, and I doubt it will affect many people. Otherwise, the extra method is unfortunately necessary.
04-05-2016

It would best not to introduce this public method just for an implementation optimization. There is no other good use for it in the public API. It would be more practical to return a non-Modifiable set of the availableZoneIds that would avoid the copy and for callers that did not need to modify it would be a better choice.
04-05-2016

Exactly right. One new static method on ZoneRulesProvider: public getAvailableZoneIdsSize() { return ZONES.size(); } (located just after getAvailableZoneIds()in the source file) Then change the two uses in ZoneIdPrinterParser and ZoneTextPrinterParser to use the new method.
04-05-2016

The ZoneRulesProvider class do not have direct way to get size of ZONES or ZoneIds. To implement the suggested solution, we need to add a new public method getAvailableZoneIdsSize() to ZoneRulesProvider which would return number of entries in ZONES list.
04-05-2016

The proposed fix seems simple and obvious to me.
02-05-2016

There is some discussion of this bug, or at least a related issue, on Stack Overflow: http://stackoverflow.com/questions/34374464/extremely-slow-parsing-of-time-zone-with-the-new-java-time-api
20-12-2015