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::getOffse
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
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
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
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
On Fri, 25 Mar 2022 15:17:02 GMT, Stephen Colebourne
wrote:
>> Claes Redestad has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Add nanoOfSecond parameter, make micro less reliant on constants
>
> src/java.base/share/classes/java/time/Zon
On Fri, 25 Mar 2022 14:35:46 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
> 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 ZoneR
On Fri, 25 Mar 2022 14:52:09 GMT, Roger Riggs wrote:
>> Done.
>>
>> Sadly it seems the smaller improvement I got on
>> `getYearFromMillisZoneRegion/-UTC` was due avoiding the added arithmetic in
>> `Instant.ofEpochSecond(sec, nanos)`:
>>
>> Benchmark Mode
On Fri, 25 Mar 2022 14:28:41 GMT, Claes Redestad wrote:
>> src/java.base/share/classes/java/time/ZoneRegion.java line 183:
>>
>>> 181: @Override
>>> 182: /* package-private */ ZoneOffset getOffset(long epochSecond) {
>>> 183: return
>>> getRules().getOffset(Instant.ofEpochSecond
On Fri, 25 Mar 2022 12:33:21 GMT, Richard Startin wrote:
>> Claes Redestad has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Add nanoOfSecond parameter, make micro less reliant on constants
>
> test/micro/org/openjdk/bench/java/time/GetYea
> 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 ZoneR
On Fri, 25 Mar 2022 14:09:03 GMT, Roger Riggs wrote:
>> Claes Redestad has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Add nanoOfSecond parameter, make micro less reliant on constants
>
> src/java.base/share/classes/java/time/ZoneRegion.
On Fri, 25 Mar 2022 12:28:58 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 allo
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
On Fri, 25 Mar 2022 12:28:58 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 allo
16 matches
Mail list logo