Code change:
The compiler struggles to optimize the for position on Iterators. Simplifying the implementation has increased the efficiency in various scenarios OMM: Old position(): #[inline] fn check<T( mut predicate: impl FnMut(T) -bool, ) -impl FnMut(usize, T) -ControlFlow<usize, usize{ #[rustcinheritoverflowchecks] move { if predicate(x) { ControlFlow::Break(i) } else { ControlFlow::Continue(i + 1) } } } self.tryfold(0, check(predicate)).breakvalue() Simplified version (There are several alternative implementations producing similar results as well): let mut position = 0; while let Some(x) = () { if predicate(x) { return Some(position); } position += 1; } None Bench results: <details </summary<br</detailsBenchmarks are named after the iterator and were run using . Ranges benefit massively (big ones by multiple orders of magnitude), while for other types, speedups are usually between 0% and 100%. A specific implementation for range calculating the position would of course be even faster, but I don't think position() is called that often on ranges. The implementation is similar to the one, which was introduced to reduce compile times , so perhaps this would help in that regard as well. However, the compiler appears to occasionally forget how to optimize the function after editing unrelated code. This also happens with the current implementation, so I don't know how reproducible the speedups are (FWIW Ranges have never failed to improve, though). I did not attempt to benchmark compilation speed, but according to the memory usage is down from 11.8 MB to 8.3 MB which looks promising. I was motivated by a on reddit, where some context and speculation can be found.
The -based implementation is likely intended to speed up position-finding in or iterators. So measuring range or slice iters doesn't exercise it well. That said, they should be equally fast for slices. Going through should end up with a very similar white-let loop. The call-tree is deeper, so this might affect optimizations. Have you tried compiling with 1CGU or LTO to see if that makes a difference? Benchmarks are fickle.
The godbolt example does show that try_fold version results in a few more instructions. looks like it's trying to do some branchless version of the accumulator increments here: while is an unconditional increment sitting in its own block. Maybe ControlFlow is not well-suited for carrying the value and the loop state at the same time? CC
I did some quick measurements for a chain of vecs: So the current impl does indeed work better for chains Yes, the difference is the ControlFlow abstraction Yes: No real differences though, results were with these settings. This made me retest an alternative I used previously (reducing ControlFlow size from <usize, usizeto <usize, ()): And this one actually beats the current one for the chain test: The chain_alt is even faster, but it's an attempt to keep the current style, updated for keeping the counter outside the fold: It isn't pretty, but it works The Assembly and IR are too long for me too really identify where the benefit comes from, curiously the faster version has more instructions, but I guess with all the jumps everywhere that doesn't mean a lot. I am interested in testing these more thoroughly, is there a nice resource with some real world data to test them on? Edit: Went digging in recent projects and I had a solution for Advent of Code Day 6 using .rposition() and .position() with the relevant part being: And changing to the alt version (with check(predicate, acc)) improved runtime from 8.8 ms to 6.2 ms, a 40% speedup! (I know there is an algebraic solution to the problem, but still)
You could make a PR and we can do a perf run. It doesn't have dedicated benchmarks that stress and I haven't checked if any of the runtime benchmarks make use of at all, but the compiler also makes use of it internally so it might show up in builds too.
Yes, we learned in that if you don't need move access to the accumulator -- either because is fine, as in that thread, or seemingly because you can , as seen here -- then it's better to use with a closure instead of needing LLVM to understand the threading through the +. (Maybe this'll be better once LLVM does better with 2-variant enums and stops losing information about them, but for now we're stuck with this.)

Related discussion:
text: P: FnMut(Self::Item) -> bool, { #[inline] <del> fn check<T>( mut predicate: impl FnMut(T) -> bool, ) -> impl FnMut(usize, T) -> ControlFlow<usize, usize> { </del> <ins> fn check<'a, T>( mut predicate: impl FnMut(T) -> bool + 'a, acc: &'a mut usize, ) -> impl FnMut((), T) -> ControlFlow<usize, ()> + 'a { </ins> #[rustc_inherit_overflow_checks] <del> move |i, x| { if predicate(x) { ControlFlow::Break(i) } else { ControlFlow::Continue(i + 1) } </del> <ins> move |_, x| { if predicate(x) { ControlFlow::Break(*acc) } else { *acc += 1; ControlFlow::Continue(()) } </ins> } } <del> self.try_fold(0, check(predicate)).break_value() </del> <ins> let mut acc = 0; self.try_fold((), check(predicate, &mut acc)).break_value() </ins> } /// Searches for an element in an iterator from the right, returning its