The following example is a benchmark of core::Zip::next_back() with iterators of very different lengths.

use std::iter::*; use std::time::Instant; fn main() { let start = Instant::now(); for _ in 0..10_000 { once(0).zip(repeat_n(1, 1_000_000)).next(); } let end = Instant::now(); println!("next(): {:.2} ns/iter", end.duration_since(start).as_secs_f64() * 100_000f64); let start = Instant::now(); for _ in 0..10_000 { once(0).zip(repeat_n(1, 1_000_000)).next_back(); } let end = Instant::now(); println!("next_back(): {:.2} ns/iter", end.duration_since(start).as_secs_f64() * 100_000f64); }

It outputs:

next(): 0.02 ns/iter next_back(): 357483.04 ns/iter 

This is caused by Zip::next_back() calling the longer iterator's next_back() until both iterators are the same length. For iterators not implementing TrustedRandomAccessNoCoerce this could be sped up significantly by using advance_back_by() instead.

I'm not sure if this can be optimised for iterators implementing TrustedRandomAccessNoCoerce but not TrustedRandomAccess, as they use the same next_back() implemntation but cannot safely use advance_back_by().

Rust version

rustc 1.90.0 (1159e78c4 2025-09-14) binary: rustc commit-hash: 1159e78c4747b02ef996e55082b704c09b970588 commit-date: 2025-09-14 host: x86_64-pc-windows-msvc release: 1.90.0 LLVM version: 20.1.8