Uploaded image for project: 'JDK'
  1. JDK
  2. JDK-8074003

java.time.zone.ZoneRules.getOffset(java.time.Instant) can be optimized

    Details

    • Type: Enhancement
    • Status: Resolved
    • Priority: P4
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 9
    • Component/s: core-libs
    • Labels:
    • Subcomponent:
    • Introduced In Version:
      8
    • Resolved In Build:
      b64

      Backports

        Description

        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. The simplest form of optimization is for the ZoneOffsetTransition implementation to keep both LocalDateTime variant and epochSecond variant of transition time as the object's state.

          Issue Links

            Activity

            plevart Peter Levart created issue -
            plevart Peter Levart made changes -
            Field Original Value New Value
            Description 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. The simplest for of optimization is for the ZoneOffsetTransition implementation to keep both LocalDateTime variant and eposhSecond variant of transition time as the object's state. 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. The simplest form of optimization is for the ZoneOffsetTransition implementation to keep both LocalDateTime variant and eposhSecond variant of transition time as the object's state.
            plevart Peter Levart made changes -
            Description 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. The simplest form of optimization is for the ZoneOffsetTransition implementation to keep both LocalDateTime variant and eposhSecond variant of transition time as the object's state. 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. The simplest form of optimization is for the ZoneOffsetTransition implementation to keep both LocalDateTime variant and epochSecond variant of transition time as the object's state.
            Show
            plevart Peter Levart added a comment - Here's the proposed patch: http://cr.openjdk.java.net/~plevart/jdk9-dev/ZoneOffsetTransition.epochSecond/webrev.01/
            rriggs Roger Riggs made changes -
            Link This issue relates to JDK-8079063 [ JDK-8079063 ]
            hgupdate HG Updates made changes -
            Status New [ 10000 ] Open [ 1 ]
            Hide
            hgupdate HG Updates added a comment -
            URL: http://hg.openjdk.java.net/jdk9/dev/jdk/rev/5441e96e46fa
            User: plevart
            Date: 2015-05-04 08:14:18 +0000
            Show
            hgupdate HG Updates added a comment - URL: http://hg.openjdk.java.net/jdk9/dev/jdk/rev/5441e96e46fa User: plevart Date: 2015-05-04 08:14:18 +0000
            hgupdate HG Updates made changes -
            Status Open [ 1 ] Resolved [ 5 ]
            Resolved In Build team [ 17324 ]
            Fix Version/s 9 [ 14949 ]
            Resolution Fixed [ 1 ]
            coffeys Sean Coffey made changes -
            Labels noreg-perf
            Hide
            hgupdate HG Updates added a comment -
            URL: http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/5441e96e46fa
            User: lana
            Date: 2015-05-13 21:19:45 +0000
            Show
            hgupdate HG Updates added a comment - URL: http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/5441e96e46fa User: lana Date: 2015-05-13 21:19:45 +0000
            hgupdate HG Updates made changes -
            Resolved In Build team [ 17324 ] master [ 18256 ]
            hgupdate HG Updates made changes -
            Resolved In Build master [ 18256 ] b64 [ 17632 ]
            hgupdate HG Updates made changes -
            Link This issue backported by JDK-8084831 [ JDK-8084831 ]

              People

              • Assignee:
                plevart Peter Levart
                Reporter:
                plevart Peter Levart
              • Votes:
                0 Vote for this issue
                Watchers:
                3 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved: