Please review this small performance tweak `ArrayDeque`.
`ArrayDeque` has an invariant in which any unused elements in the array must be
null. In a couple of places, the code is setting contiguous ranges of elements
to null using `for()` loops. This can be both simplified and sped up by using
`
On Mon, 19 May 2025 07:25:17 GMT, Tagir F. Valeev wrote:
> I'm not sure whether we should specify exactly the behavior in case if the
> comparator returns 0. I feel that it could be a useful invariant that
> `Comparator.min(a, b)` and `Comparator.max(a, b)` always return different
> argument,
On Thu, May 15, 2025 at 2:02 AM Peter Levart wrote:
> On 4/11/25 6:19 PM, Archie Cobbs wrote:
> > Sorry if that wasn't clear - I didn't mean power-of-two exponential
> > growth, I meant all segments were literally fixed size, like 256 or
> > something (or maybe
On Thu, 15 May 2025 06:07:06 GMT, Alan Bateman wrote:
> Are you planning to add some JMH benchmarks to go with this?
I wasn't planning to, but I'm inferring from your question that you'd prefer to
see one.
Which also makes me curious. I'd be shocked if this were slower, but even if
not, I won
ied and sped up
> by using `Arrays.fill()` instead.
Archie Cobbs has updated the pull request incrementally with one additional
commit since the last revision:
Blackhole ArrayDeque to ensure it's not ignored by the compiler.
-
Changes:
- all: https://git.openjdk.o
On Thu, 15 May 2025 18:33:22 GMT, Raffaello Giulietti
wrote:
> Here are many
> [exmaples](https://github.com/openjdk/jmh/tree/master/jmh-samples/src/main/java/org/openjdk/jmh/samples)
> on how to correctly use JMH.
>
> A
> [blackhole](https://github.com/openjdk/jmh/blob/master/jmh-samples/sr
On Thu, 15 May 2025 19:53:03 GMT, ExE Boss wrote:
> Note that `Arrays.fill(…)` is simply a `for(…)` loop with an additional range
> check
Interesting... I was assuming that most of the "bulk" methods in `Arrays` were
being hand-optimized with special hardware magic (e.g., vector instructions),
On Thu, May 22, 2025 at 3:31 PM John R Rose wrote:
> > Update benchmark to reflect new fill method
>
> Related discussion at the hardware level:
>
> https://github.com/openjdk/jdk/pull/25147#issuecomment-2902463076
>
This discussion spurred me to ask a dumb question. Apologies in advance,
just
.wikipedia.org/wiki/Automatic_vectorization
> [2] https://youtu.be/rXv2-lN5Xgk?t=1518
> --
> *From:* core-libs-dev on behalf of
> Archie Cobbs
> *Sent:* Thursday, May 22, 2025 10:58 PM
> *To:* John R Rose
> *Cc:* core-libs-dev@openjdk.org
> *Subject:* Re: RFR: 8357531: The `
On Wed, May 21, 2025 at 11:30 AM Paul Sandoz wrote:
> I consider this a “known unknown” (in the words of Mr. Rumsfeld). We would
> need to explore this area throughly, which includes the interconnection
> with Serialization 2.0, before we really know what we can and should do in
> the near and lo
Period is like Duration - they are both "lengths of time", just using
different units (so they are both a TemporalAmount).
Similar to how LocalDateTime vs. Instant are both "points in time", just
using different units (so they are both a Temporal).
But you bring up a good point - perhaps Calendar
Just MHO...
This is kind of like asking "What's the best way to waste electricity?"
It's a nebulous question until you specify what "best" means in this odd
scenario
-Archie
On Sun, Jun 15, 2025 at 11:09 AM Markus KARG wrote:
> Recently I was asked by a programmer, what to do if there sim
201 - 212 of 212 matches
Mail list logo
