-
Notifications
You must be signed in to change notification settings - Fork 309
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 "loops of next" #818
Specialize "loops of next" #818
Conversation
And then no need for a named loop anymore.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks.
while let Some(v) = self.iter.iter.next_back() { | ||
if let Entry::Vacant(entry) = self.iter.used.entry(v) { | ||
let UniqueBy { iter, used, .. } = &mut self.iter; | ||
iter.rev().find_map(|v| { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Off-topic: Is it strange that there's rfind
, but no rfind_map
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's not off-topic to me. I was wondering the same question while writing this.
Maybe there is no large performance gain to expect compare to .rev().method()
. I searched a bit but did not find anything.
More generally, DoubleEndedIterator
does not have a lot of methods.
There are some cases where
next/next_back
is repeatedly called in a loop, where a specialized method would do the same job, except it might be faster if the iterator they adapt has some specialized faster method.It was the case in #816.
Those benchmarks are not that impressive, they are based on slices that roughly reimplement the while loop themselves. But if the iterator they adapt have a specialized
try_[r]fold
on whichfind/find_map/rfind
usually rely, then it should be faster.The code is shorter in multiple cases and I believe clearer.
The
partition
function did not have any benchmark, there is now one and there are no difference, both 330µs.