On Tue, 27 Jan 2026 18:22:52 GMT, Oli Gillespie <[email protected]> wrote:
> 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. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28608#discussion_r2733346122
