为何std::reverse_iterator比先std::reverse再迭代的性能差？

Great question! The massive performance gap you're observing between std::reverse_iterator and the "reverse-then-iterate" approach comes down to core details of how reverse iterators work and how compilers optimize different code patterns. Let's break this down:

1. Reverse Iterators Add Hidden Overhead #

A std::reverse_iterator isn't a purpose-built reverse traversal tool—it's a wrapper around a regular iterator, and that wrapper introduces extra work on every iteration:

• When you call ++it on a reverse iterator, it actually runs -- on the underlying base iterator.
• When you dereference a reverse iterator (*it), it doesn't directly access the value. Instead, it temporarily adjusts the base iterator to point to the previous element, dereferences it, then restores the base iterator's position (or uses equivalent logic like *(base() - 1)).

For a loop over 100,000 elements, these tiny per-iteration costs stack up into a noticeable slowdown.

2. Compilers Struggle to Optimize Reverse Iterator Abstractions #

Modern compilers excel at optimizing simple, direct memory access—but they hit barriers with wrapped, indirect abstractions like std::reverse_iterator:

• In foo1, after reversing the vector, your loop uses a regular iterator (or range-based for, which compiles to a regular iterator) to traverse contiguous memory in order. Compilers can apply aggressive optimizations here: loop unrolling, SIMD vectorization, and cache prefetching all work seamlessly because it's a straightforward linear access pattern.
• In foo2, the reverse iterator's indirection confuses the optimizer. It can't easily recognize that the underlying access is still contiguous memory (even in reverse), so it can't apply the same level of optimizations. The extra steps in the reverse iterator's operator++ and operator* prevent the compiler from generating the tight, efficient machine code it produces for regular iterator loops.

3. Your Test Case Amplifies the Difference #

Your specific code makes this gap even more obvious:

• std::reverse on a std::vector is blazingly fast. It just swaps elements from the start/end toward the center with simple pointer arithmetic—no allocations, no complex logic. The cost of reversing twice is negligible compared to the loop overhead difference.
• When you swapped the range-based for for a manual regular loop and saw a small slowdown, that's just because range-based for loops often get slightly better compiler optimizations (they avoid redundant checks). But both are still using direct regular iterators, so they're way faster than reverse iterators.

Quick Way to Confirm #

If you want to see this in action, check the assembly code generated for both loops. You'll notice the foo1 loop compiles to a tight sequence of minimal instructions, while the foo2 loop has extra lines handling the reverse iterator's wrapper logic.

内容的提问来源于stack exchange，提问作者J.R.