RFR: JDK-8074003 java.time.zone.ZoneRules.getOffset(java.time.Instant) can be optimized
Roger.Riggs at Oracle.com
Mon Apr 27 21:58:53 UTC 2015
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?
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:
> The discussion about it is intermingled with the
> ZoneId.systemDefault() discussion and starts about here:
> 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
More information about the core-libs-dev