On Tue, 27 Jan 2026 18:39:54 GMT, Chen Liang <[email protected]> wrote:
>> Thanks for looking. >> >> I suppose you mean Spliterators.spliteratorUnknownSize? >> >> Hmm - I made the change this way to be consistent with the existing >> `SubMapKeyIterator` and `DescendingSubMapKeyIterator`, simply adding the >> same functionality for the Entry versions. Do you think *those* are >> overcomplicated too, or there's a reason they're like that that doesn't >> apply to the Entry versions? I don't know why they were originally added, to >> be honest, I didn't find much useful context in the history. >> >> I don't know Spliterator well enough to spot any subtle behavioural >> differences, that's one reason I chose to follow the existing patterns. >> >> DescendingSubMapEntryIterator is SORTED but SubMapEntryIterator is not, so >> I'd have to account for that too. > >> I suppose you mean Spliterators.spliteratorUnknownSize? > > Yes. Thanks for corecting me. > >> Hmm - I made the change this way to be consistent with the existing >> SubMapKeyIterator and DescendingSubMapKeyIterator, simply adding the same >> functionality for the Entry versions. > > I made the recommendation given the starting point is to address a > performance regression, instead of to enhance the sub-map entry spliterator > to be on par with the `DescendingSubMapKeyIterator`. > > From this starting point, I believe we can easily identify `EntrySetView` > inherits `Set::spliterator` which is slow because the spliterator calls > `size()` frequently. This root problem is easily fixed with using > `Spliterators.spliteratorUnknownSize`, which also has the minimal behavioral > impact. > > In contrast, functional enhancement to spliterators is really a can of worms > where you can never find an end - sometimes you add more flags, sometimes > other splitting strategies. And in your example, you already have a test case > failing due to the functional enhancements while you did make new tests to > verify them. > > So let's keep it simple, fix the bug, and leave the functional enhancements > for another time. This also makes backporting the fix much easier. Okay sounds good to me! Thanks for the suggestion, I'll update later this week. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28608#discussion_r2733671479
