On Mon, 24 Feb 2025 08:44:00 GMT, Tagir F. Valeev wrote:
> It appears that the benchmark was erroneous. The combination of "tailMap"
> mode and comparator = true didn't work correctly, as the comparator is
> descending. This PR changes the benchmark to use headMap instead of tailMap
> in compa
On Mon, 2 Sep 2024 16:19:01 GMT, fabioromano1 wrote:
>> This implementation of MutableBigInteger.leftShift(int) optimizes the
>> current version, avoiding unnecessary copy of the MutableBigInteger's value
>> content and performing the primitive shifting only in the original portion
>> of the v
On Tue, 3 Sep 2024 15:49:01 GMT, fabioromano1 wrote:
> > It would be nice to see some benchmarks where it gives performance benefits.
>
> @kuksenko Try to run the benchmark of the `BigInteger`'s square root, maybe
> there the benefits are more visible...
"maybe"
So, you don't have proof th
On Mon, 2 Sep 2024 16:19:01 GMT, fabioromano1 wrote:
>> This implementation of MutableBigInteger.leftShift(int) optimizes the
>> current version, avoiding unnecessary copy of the MutableBigInteger's value
>> content and performing the primitive shifting only in the original portion
>> of the v
7;t have benchmarks targeting lambdas startup.
From: Mandy Chung ***@***.***>
Sent: Wednesday, April 17, 2024 9:32 AM
To: openjdk/jdk
Cc: Sergey Kuksenko; Mention
Subject: [External] : Re: [openjdk/jdk] 8294960: Convert
java.base/java.la
On Mon, 10 Jul 2023 08:17:59 GMT, Hamlin Li wrote:
>> @Hamlin-Li
>> The PR is fully correct.
>> Don't forget, every Java instance method has a specific argument which
>> called "this". That is why @State annotation is working.
>
> @kuksenko @swati-sha Thanks for explanation. I can understand w
On Fri, 7 Jul 2023 08:29:06 GMT, Hamlin Li wrote:
>> The below benchmark files have scaling issues due to cache contention and
>> leads to poor scaling when run on multiple threads. The patch sets the scope
>> from benchmark level to thread level to fix the issue:
>> - org/openjdk/bench/java/io
On Fri, 10 Feb 2023 10:00:05 GMT, Xiaowei Lu wrote:
> [JDK-8269667](https://bugs.openjdk.org/browse/JDK-8269667) has uncovered the
> poor performance of BigDecimal.divide under certain circumstance.
>
> We confront similar situations when benchmarking Spark3 on TPC-DS test kit.
> According to
On Fri, 10 Feb 2023 10:00:05 GMT, Xiaowei Lu wrote:
> [JDK-8269667](https://bugs.openjdk.org/browse/JDK-8269667) has uncovered the
> poor performance of BigDecimal.divide under certain circumstance.
>
> We confront similar situations when benchmarking Spark3 on TPC-DS test kit.
> According to
On Fri, 10 Feb 2023 10:00:05 GMT, Xiaowei Lu wrote:
> [JDK-8269667](https://bugs.openjdk.org/browse/JDK-8269667) has uncovered the
> poor performance of BigDecimal.divide under certain circumstance.
>
> We confront similar situations when benchmarking Spark3 on TPC-DS test kit.
> According to
On Tue, 3 Jan 2023 23:25:39 GMT, fabioromano1 wrote:
> The enanchment is useful for applications that make heavy use of BitSet
> objects as sets of integers, and therefore they need to make a lot of calls
> to cardinality() method, which actually require linear time in the number of
> words in
11 matches
Mail list logo
