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
