RFR: 8327858: Improve spliterator and forEach for single-element immutable collections [v2]
Stuart Marks
smarks at openjdk.org
Wed Sep 25 20:55:39 UTC 2024
On Fri, 22 Mar 2024 09:25:06 GMT, Viktor Klang <vklang at openjdk.org> wrote:
>> Benchmark Mode Cnt Score Error Units
>> ImmutableColls.forEachOverList thrpt 15 361.423 ± 8.751 ops/us
>> ImmutableColls.forEachOverSet thrpt 15 79.158 ± 5.064 ops/us
>> ImmutableColls.getOrDefault thrpt 15 244.012 ± 0.943 ops/us
>> ImmutableColls.iterateOverList thrpt 15 152.598 ± 3.687 ops/us
>> ImmutableColls.iterateOverSet thrpt 15 61.969 ± 4.453 ops/us
>>
>> The 3 results are also available at https://gist.github.com/f0b4336e5b1cf9c5299ebdbcd82232bf, where baseline is the master this patch currently is based on (which has WhiteBoxResizeTest failures), patch-0 being the current code, and patch-1 being your proposal (uncommited patch below).
>>
>> diff --git a/src/java.base/share/classes/java/util/ImmutableCollections.java b/src/java.base/share/classes/java/util/ImmutableCollections.java
>> index fc232a521fb..f38b093cf60 100644
>> --- a/src/java.base/share/classes/java/util/ImmutableCollections.java
>> +++ b/src/java.base/share/classes/java/util/ImmutableCollections.java
>> @@ -916,12 +916,9 @@ public <T> T[] toArray(T[] a) {
>> @Override
>> @SuppressWarnings("unchecked")
>> public void forEach(Consumer<? super E> action) {
>> - if (e1 == EMPTY) {
>> - action.accept(e0); // implicit null check
>> - } else {
>> - action.accept(REVERSE ? (E)e1 : e0); // implicit null check
>> - action.accept(REVERSE ? e0 : (E)e1);
>> - }
>> + action.accept((!REVERSE || e1 == EMPTY) ? e0 : (E) e1); // implicit null check
>> + if (e1 != EMPTY)
>> + action.accept(!REVERSE ? (E) e1 : e0);
>> }
>>
>> @Override
>>
>>
>>
>> My testing shows that the existing version I have is most likely faster than your proposed version.
>>
>> Also note that the test failures are from WhiteBoxResizeTest that's fixed in latest master; I decide not to pull as not to invalidate the existing benchmark baselines.
>
> Thanks. I was mostly trying to gauge what the bottleneck might be.
Another alternative is this:
if (e1 == EMPTY) {
action.accept(e0); // implicit null check
} else if (REVERSE) {
action.accept((E)e1); // implicit null check
action.accept(e0);
} else {
action.accept(e0); // implicit null check
action.accept((E)e1);
}
I don't care about speed, so don't benchmark unless you're really really curious for yourself. I'm more concerned about clarity. The two ternary operators are a bit weird. My suggestion is bulkier but maybe clearer -- or maybe not.
There is also the fact that the fields are `E e0` and `Object e1` which adds clutter from casting along with some unpleasant asymmetry. But that's a separate matter.
Anyway I'm not so fond of my suggestion, so I won't advocate for it strenuously. Mostly just putting out for discussion. The current code is probably fine.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/15834#discussion_r1775979779
More information about the core-libs-dev
mailing list