On Tue, 27 Jan 2026 20:17:18 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. > > Okay sounds good to me! Thanks for the suggestion, I'll update later this > week. I created https://github.com/openjdk/jdk/pull/29485 to add test cases before making this change - that required a slight functional tweak so I didn't want to include it in this change. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28608#discussion_r2741453002
