RFR: JDK-8074003 java.time.zone.ZoneRules.getOffset(java.time.Instant) can be optimized

[Stephen Colebourne]

TzdbZoneRulesProvider parses the byte[] of TZ data on demand when a
ZoneId is first requested. So, the ZoneOffsetTransition will not be
created unless a ZoneId is during startup.
Stephen

On 27 April 2015 at 22:58, Roger Riggs <Roger.Riggs at oracle.com> wrote:
> Hi Peter,
>
> Caching the epochSecond moves the computation from a relatively lazy version
> to creation when it would be performed eagerly for every transition.
> Is there a quick way to see if it will have an impact on the startup time?
>
> Roger
>
>
>
> On 4/27/2015 12:24 PM, Peter Levart wrote:
>>
>> Hi again,
>>
>> Here's another optimization to be reviewed that has been discussed a while
>> ago (just rebased from webrev.01) and approved by Stephen:
>>
>>
>> http://cr.openjdk.java.net/~plevart/jdk9-dev/ZoneOffsetTransition.epochSecond/webrev.02/
>>
>>
>> The discussion about it is intermingled with the ZoneId.systemDefault()
>> discussion and starts about here:
>>
>>
>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-February/031873.html
>>
>>
>> The rationale for the optimization is speeding-up the conversion from
>> epoch time to LocalDateTime. This conversion uses
>> ZoneRules.getOffset(Instant) where there is a loop over
>> ZoneOffsetTransition[] array that searches for 1st transition that has its
>> toEpochSecond value less than the Instant's epochSecond. This calls
>> ZoneOffsetTransition.toEpochSecond repeatedly, converting
>> ZoneOffsetTransition.transition which is a LocalDateTime to epochSecond.
>> This repeated conversion is unnecessary, as ZoneOffsetTransition[] array is
>> part of ZoneRules which is cached. Optimizing the ZoneOffsetTransition
>> implementation (keeping both LocalDateTime variant and eposhSecond variant
>> of transition time as the object's state) speeds up this conversion.
>>
>>
>> Regards, Peter
>>
>