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.ri...@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 >> >
