Open kinto-b opened 5 months ago
All modified and coverable lines are covered by tests :white_check_mark:
Project coverage is 94.44%. Comparing base (
6814180
) to head (73d78c5
). Report is 54 commits behind head on master.
:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.
Same for #918 and #919, it uses a HashMap
and therefore heap allocates and (securely but slowly) hash things, those two things are the bottleneck. There is not much to expect of such specialization without improving that front:
HashMap<_, _, RandomState>
.With a faster hasher, maybe that specialize fold
would a bit more beneficial for the benchmark to show some improvement. We might want to revisit those PRs once I make a more general DuplicatesByIn
.
I referenced your PRs in https://github.com/rust-itertools/itertools/issues/755#issuecomment-1728319901 to avoid people from making duplicates PRs.
There would also be rfold
to consider alongside fold
.
Side note:
I'm aware specialization benchmarks are slow to build (2 minutes for me), and 8 seconds per benchmark to run (which is ok).
I usually comment out (or simply remove) benchmarks from the bench_specializations
macro declaration (without committing changes) to have fast benchmarks. With that, I don't mind re-run benchmarks.
It's a pain but it's a huge file with a lot of iterators and methods to bench, there is no simple fix to avoid building benchmarks we are not gonna use.
Relates to #755. I didn't grab the output earlier (is there a way to print without re-benchmarking?) but this makes no difference to the performance. Submitting a PR for record keeping sake