8072784: Better spliterator implementation for BitSet.stream()
Paul Sandoz
paul.sandoz at oracle.com
Tue Nov 22 17:26:18 UTC 2016
> On 21 Nov 2016, at 20:00, Tagir Valeev <amaembo at gmail.com> wrote:
>
> Hello!
>
>> Hi Tagir,
>>
>> In the original issue i was pondering using SIZED for smaller bit sets and non-SIZED for larger bit sets, since we stride over the longs themselves when calculating the size (should be intrinsic to count the set bits, at least on x86). Supporting both is fairly simple, but you are correct not reporting SIZED would simplify things further and it may not matter in practice.
>>
>> Can you log an issue? I will follow up with some performance analysis.
>
> Sure, here it is:
> https://bugs.openjdk.java.net/browse/JDK-8170159
>
Thanks!
> Probably it would be optimal not to call cardinality until it's
> actually queried. Unfortunately current stream implementation always
> queries getExactSizeIfKnown() (passing it into sink.begin()) even if
> it's not actually used (which is most of the cases).
>
The expectation being that if a spliterator reports SIZED then the exact size it can be calculated efficiently, which is not necessarily the case for BitStream.
For sequential streams i think you have a point, but for parallel streams the estimated size will also be used for the splitting threshold. (A spliterator cannot report both an estimated size and an exact size.)
Paul.
More information about the core-libs-dev
mailing list