Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Specialize MapForGrouping::fold #873

Merged

Conversation

Philippe-Cholet
Copy link
Member

@Philippe-Cholet Philippe-Cholet commented Feb 9, 2024

Related to #755

MapForGrouping is only internally used by GroupingMapBy and it only calls for_each on it (which in turn rely on fold). So I allow the clippy lint missing_trait_methods because specialize other methods is simply useless. (In case we run clippy with warning it.)

I could replace next body by unreachable!() and it would still work fine.
Anyway, it will disappear from test coverage now that we have one (see here).

I previously wandered how to test and benchmark this:

  • The current tests will test this.
  • And I guess I could benchmark this fold specialization through some into_grouping_map_by benchmark but I simply don't think it's worth the time: no doubt adapted_iterator.map.fold is faster than the default fold calling next repeatedly. We just don't know how much faster.

Note that all GroupingMapBy methods ultimately rely on this fold so this specialization will improve performance for all its methods.

`MapForGrouping` is only internally used by `GroupingMapBy` and it only calls `for_each` on it (which in turn rely on `fold`). So I allow the clippy lint `missing_trait_methods` because specialize other methods is simply useless.
I could replace `next` body by `unreachable!()` and it would still work fine. Anyway, it will disappear from test coverage now that we have one.
I previously wandered how to test and benchmark this. The current tests will test this. And I guess I could benchmark this `fold` specialization through some `into_grouping_map_by` benchmark but I simply don't think it's worth the time: no doubt `adapted_iterator.map.fold` is faster than the default `fold` calling `next` repeatedly.
Note that all `GroupingMapBy` methods ultimately rely on this `fold` so this specialization will improve performance for all its methods.
@Philippe-Cholet Philippe-Cholet added this to the next milestone Feb 9, 2024
Copy link

codecov bot commented Feb 9, 2024

Codecov Report

All modified and coverable lines are covered by tests ✅

Comparison is base (6814180) 94.38% compared to head (79f76be) 94.15%.
Report is 4 commits behind head on master.

Additional details and impacted files
@@            Coverage Diff             @@
##           master     #873      +/-   ##
==========================================
- Coverage   94.38%   94.15%   -0.24%     
==========================================
  Files          48       48              
  Lines        6665     6673       +8     
==========================================
- Hits         6291     6283       -8     
- Misses        374      390      +16     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

Copy link
Member

@phimuemue phimuemue left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thank you.

OT: It seems that MapForGrouping is (essentially) just a special cased Map. IIRC we have some of these special-cased Maps/Folds (e.g. MapOk, FilterOk, FilterMapOk). I wonder if we could - once MSRV reaches 1.75 - replace them by Filter<InnerIterator, impl FnMut(InnerIterator::Item)->V> or the like. Then, they would automatically inherit the specialized methods.

@phimuemue phimuemue added this pull request to the merge queue Feb 12, 2024
Merged via the queue into rust-itertools:master with commit c3f6cf9 Feb 12, 2024
13 checks passed
@Philippe-Cholet Philippe-Cholet deleted the fold-mapforgrouping branch February 12, 2024 10:31
@phimuemue
Copy link
Member

After a second thought, I'm pretty sure type MapForGrouping<I, F> = MapSpecialCase<I, MapForGroupingFn<F>> would be cleaner.

@Philippe-Cholet
Copy link
Member Author

Seems cleaner indeed.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants