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

[Roger Riggs]

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
>