Cadenas de iteradores: por qué son de coste cero

Cierra el nivel una afirmación que suena a exageración y no lo es: una cadena de iteradores —iter().filter().map().sum()— compila, con optimizaciones, al mismo código máquina que el bucle con índices que escribirías a mano. No “parecido”, ni “casi”. El mismo. No es un acto de fe ni una aproximación optimista: es un hecho verificable en el ensamblador que emite el compilador. Esta lección desarma la maquinaria que lo hace posible, para que dejes de sospechar de la abstracción y la uses por defecto.

La promesa, hecha comprobable

La afirmación es fuerte. Esta cadena de iteradores…

fn suma_pares_x10(v: &[i32]) -> i32 {
    v.iter().filter(|&&x| x % 2 == 0).map(|&x| x * 10).sum()
}

…y este bucle escrito a mano…

fn suma_pares_x10_manual(v: &[i32]) -> i32 {
    let mut total = 0;
    for &x in v {
        if x % 2 == 0 {
            total += x * 10;
        }
    }
    total
}

…producen, compilados con optimizaciones, el mismo código máquina. La cadena de alto nivel no lleva penalización alguna respecto al bucle que un programador de C escribiría a regañadientes: ni una asignación de más, ni una indirección, ni una llamada de función residual. Se comprueba mirando el ensamblador emitido, no confiando en la promesa.

Por qué: monomorfización, inlining e iteración interna

Tres mecanismos, actuando en secuencia, disuelven la abstracción hasta hacerla desaparecer:

Monomorfización. Cada adaptador es un tipo genérico distinto —Filter<Iter<i32>>, luego Map<Filter<...>>—. Al usarlos con tipos concretos, el compilador genera versiones especializadas, sin genericidad residual. La cadena se vuelve un tipo anidado concreto, sin una sola decisión de tipo pendiente para la ejecución.

Inlining de next. El next de cada adaptador es diminuto: el de map llama al next del iterador interior y le aplica la clausura; el de filter lo invoca en bucle hasta que el predicado pasa. Como son tan pequeños, el optimizador los inlina unos dentro de otros, colapsando la pila de llamadas anidadas en un único cuerpo sin saltos de función.

Iteración interna. Un consumidor como sum no tira elemento a elemento desde fuera; delega en fold o try_fold, que recorren el iterador desde dentro, en un bucle cerrado que el propio adaptador controla. Esa iteración interna le entrega al optimizador un bucle compacto y contiguo, ideal para eliminar comprobaciones de límites y, cuando procede, vectorizar.

// sum se apoya en fold: iteracion interna, un bucle cerrado
let total: i32 = (1..=100).fold(0, |acc, x| acc + x);
assert_eq!(total, 5050);

El resultado combinado: los tipos desaparecen (monomorfización), las llamadas desaparecen (inlining) y queda un solo bucle ceñido (iteración interna) que el backend optimiza igual que optimizaría el bucle manual, porque a esas alturas son el mismo bucle.

flowchart TB
chain[Cadena iter filter map sum] --> mono[Monomorfizacion tipos concretos anidados]
mono --> inl[Inlining de cada next diminuto]
inl --> intern[Iteracion interna un bucle cerrado]
intern --> asm[Mismo ensamblador que el bucle a mano]
style chain fill:#cba6f7,color:#11111b
style inl fill:#89b4fa,color:#11111b
style asm fill:#a6e3a1,color:#11111b

Cuando el iterador gana al bucle ingenuo

El coste cero no significa “empata siempre con el bucle”: a veces la cadena de iteradores supera al bucle manual ingenuo, y la razón es de nuevo la iteración interna. Cuando indexas un slice a mano con v[i], el compilador debe insertar una comprobación de límites en cada acceso, porque i podría salirse del rango. Un iterador recorre por punteros internos que, por construcción, no se salen: no necesita esa comprobación.

// Bucle por indice: cada v[i] puede exigir comprobacion de limites
fn por_indice(v: &[i32]) -> i32 {
    let mut s = 0;
    for i in 0..v.len() {
        s += v[i]; // acceso indexado
    }
    s
}

// Iterador: recorre sin indexar, sin comprobaciones de limites
fn por_iterador(v: &[i32]) -> i32 {
    v.iter().sum()
}

En la práctica, el optimizador suele demostrar que el índice del primer caso nunca se sale y elimina también sus comprobaciones, con lo que ambos empatan. Pero cuando no puede probarlo —accesos menos regulares, índices calculados—, el iterador conserva su ventaja sin esfuerzo. La moraleja invierte el prejuicio de siempre: el estilo de alto nivel no solo no penaliza, sino que a menudo le da al compilador más información con la que optimizar que el bucle escrito a mano.

Cuándo se rompe, y cómo ayudar

El coste cero es la norma, pero no una garantía mágica: se apoya en que el optimizador pueda ver e inlinar toda la cadena. Se resiente cuando:

• Interpones despacho dinámico. Un Box<dyn Iterator> o una clausura tras dyn FnMut mete una vtable en medio: el optimizador ya no puede inlinar a través de ella. El coste cero es un privilegio del despacho estático.
• Cruzas fronteras opacas. Una función no inlinable a mitad de la cadena, o un límite entre unidades de compilación sin optimización cruzada, corta la fusión.
• Fuerzas materialización. Un collect intermedio a un Vec que solo vuelves a iterar asigna memoria sin necesidad; deja la cadena perezosa hasta el consumidor final.

La regla práctica: mantén las clausuras concretas —no las envuelvas en Box<dyn> sin motivo—, evita los collect intermedios y confía en el consumidor perezoso. Si mides una diferencia, compara el ensamblador con cargo asm antes de reescribir a mano; casi siempre descubrirás que ya eran idénticos.