Re: RFR: 8283681: Improve ZonedDateTime offset handling [v3]
On Fri, 25 Mar 2022 17:27:32 GMT, Naoto Sato wrote:
>> 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
>
> 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.
It was somewhat intentional to do it like way in this microbenchmark experiment
to check that the `toZoneId()` doesn't cause surprises and ideally that it
doesn't cost anything.
-
PR: https://git.openjdk.java.net/jdk/pull/7957
Re: RFR: 8283681: Improve ZonedDateTime offset handling [v3]
On Fri, 25 Mar 2022 15:16:42 GMT, Claes Redestad 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 Thanks for reviews! - PR: https://git.openjdk.java.net/jdk/pull/7957
Re: RFR: 8283681: Improve ZonedDateTime offset handling [v3]
On Fri, 25 Mar 2022 15:16:42 GMT, Claes Redestad 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 rriggs (Reviewer). - PR: https://git.openjdk.java.net/jdk/pull/7957
Re: RFR: 8283681: Improve ZonedDateTime offset handling [v3]
On Fri, 25 Mar 2022 15:16:42 GMT, Claes Redestad 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
Re: RFR: 8283681: Improve ZonedDateTime offset handling [v3]
On Fri, 25 Mar 2022 15:16:42 GMT, Claes Redestad 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 LGTM - Marked as reviewed by scolebourne (Author). PR: https://git.openjdk.java.net/jdk/pull/7957
Re: RFR: 8283681: Improve ZonedDateTime offset handling [v3]
> 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 - Changes: - all: https://git.openjdk.java.net/jdk/pull/7957/files - new: https://git.openjdk.java.net/jdk/pull/7957/files/355f192a..a04589b7 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk=7957=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk=7957=01-02 Stats: 35 lines in 5 files changed: 29 ins; 0 del; 6 mod Patch: https://git.openjdk.java.net/jdk/pull/7957.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7957/head:pull/7957 PR: https://git.openjdk.java.net/jdk/pull/7957
