On Fri, 25 Mar 2022 15:16:42 GMT, Claes Redestad <redes...@openjdk.org> wrote:
>> Richard Startin prompted me to have a look at a case where java.time >> underperforms relative to joda time >> (https://twitter.com/richardstartin/status/1506975932271190017). >> >> It seems the java.time test of his suffer from heavy allocations due >> ZoneOffset::getRules allocating a new ZoneRules object every time and escape >> analysis failing to do the thing in his test. The patch here adds a simple >> specialization so that when creating ZonedDateTimes using a ZoneOffset we >> don't query the rules at all. This removes the risk of extra allocations and >> slightly speeds up ZonedDateTime creation for both ZoneOffset (+14%) and >> ZoneRegion (+5%) even when EA works like it should (the case in the here >> provided microbenchmark). > > Claes Redestad has updated the pull request incrementally with one additional > commit since the last revision: > > Override ZoneOffset::normalized, cache ZoneOffset::getRules, revert change > to add 2nd parameter to ZoneId::getOffset Marked as reviewed by naoto (Reviewer). test/micro/org/openjdk/bench/java/time/GetYearBench.java line 66: > 64: private TimeZone UTC = TimeZone.getTimeZone("UTC"); > 65: > 66: private TimeZone LONDON = TimeZone.getTimeZone("Europe/London"); Nit: No need to use `TimeZone.getTimeZone()` here (and later convert them to `toZoneId()`). `ZoneId.of()` should suffice. ------------- PR: https://git.openjdk.java.net/jdk/pull/7957
