Los mitos del rendimiento: por qué el idiomático es rápido y la regla del 3 %

El nivel se cierra desmontando los mitos que más rendimiento le cuestan al programador de Rust, y son casi todos culturales, no técnicos. El mito de que el código idiomático —iteradores, Option, genéricos— es un lujo que se paga en velocidad. El mito de que toda abstracción cuesta, que empuja a evitar las que en realidad son gratis. El mito de que unsafe es más rápido, que cambia riesgo real por ganancia imaginaria. Frente a ellos, una síntesis y una regla. La síntesis: el idiomático suele ser óptimo porque las abstracciones de Rust son de coste cero (lección 1), y las pocas que sí cuestan se pueden nombrar una por una. La regla, la más antigua y la más ignorada, es la de Knuth: optimiza el 3 % que importa y deja tranquilo el 97 % restante —pero solo el perfilador sabe cuál es cuál—.

El mito del idiomático lento

El prejuicio más caro es creer que para ir rápido hay que renunciar a los iteradores y volver a los bucles con índice, como si la expresividad fuera un impuesto. Es falso, y lo viste en la lección 1: gracias a la monomorfización y al inlining, una cadena de iteradores compila al mismo bucle ceñido que el índice manual. Pero el mito no solo es falso: a menudo está invertido. El iterador es con frecuencia más rápido que el índice, porque garantiza por construcción que cada acceso está dentro de rango y le ahorra al programa las comprobaciones de límites que v[i] obliga a insertar cuando el optimizador no puede probar la cota.

// El indice fuerza a comprobar la cota si el optimizador no la demuestra.
fn maximo_indexado(v: &[i32]) -> i32 {
    let mut m = i32::MIN;
    for i in 0..v.len() { if v[i] > m { m = v[i]; } }
    m
}

// El iterador prueba la cota por construccion: sin comprobaciones, vectorizable.
fn maximo_iter(v: &[i32]) -> i32 {
    v.iter().copied().max().unwrap_or(i32::MIN)
}

Reescribir un for i in 0..v.len() como un for x in &v no es azúcar estético: le entrega al compilador una prueba que el índice le ocultaba, y esa prueba se traduce en comprobaciones eliminadas y bucles que el vectorizador se atreve a tocar. En Rust, escribir idiomático es, la mayoría de las veces, escribir rápido.

El coste real de las abstracciones

El mito complementario —que toda abstracción cuesta— es igual de dañino, porque lleva a evitar herramientas gratuitas por un miedo mal dirigido. La verdad tiene dos columnas, y el ingeniero maduro las distingue de memoria. La mayoría de las abstracciones de Rust son de coste cero: genéricos, iteradores, Option y Result, closures, newtypes, Drop. No indireccionan, no asignan, no dejan rastro en ejecución. Frente a ellas, un puñado tiene un coste real y conocido —y elegirlas es legítimo, siempre que sepas lo que pagas—.

Fíjate en que ninguno de los costes de la derecha es escandaloso: una indirección de puntero, un incremento atómico, una comprobación booleana. Son baratos en absoluto, y en la inmensa mayoría del código su precio es invisible. El error no es usarlos, es usarlos en una ruta caliente sin saber que cuestan —un Arc::clone en un bucle cerrado, un dyn en el centro de un cálculo numérico— y luego culpar al lenguaje de una lentitud que tú elegiste. Y el tercer mito, el de que unsafe acelera, se cae solo con lo anterior: el optimizador ya elimina las comprobaciones de límites del código idiomático, así que bajar a punteros crudos rara vez compra velocidad y siempre compra riesgo de comportamiento indefinido. Se mide primero; casi nunca compensa.

La regla de oro: perfila el 3 % que importa

Todo el nivel converge en una sentencia que Donald Knuth escribió en 1974 y que el tiempo no ha desgastado: «deberíamos olvidarnos de las pequeñas eficiencias, digamos el 97 % del tiempo: la optimización prematura es la raíz de todo mal. Y sin embargo no deberíamos desaprovechar nuestras oportunidades en ese 3 % crítico». La frase suele citarse a medias —solo la parte de la raíz del mal— y por eso se malentiende: Knuth no predicaba ignorar el rendimiento, sino concentrarlo donde rinde. El corolario es la ley de Amdahl: si una función ocupa el 5 % del tiempo, hacerla infinitamente rápida mejora el programa un 5 % como mucho. Optimizar fuera del punto caliente no es virtud, es desperdicio.

flowchart TD
A[Escribe codigo idiomatico y claro primero] --> B[Perfila para hallar el 3 por ciento caliente]
B --> C{Existe un punto caliente real}
C -->|no| D[Ya terminaste el idiomatico bastaba]
C -->|si| E[Optimiza solo ese punto medido]
E --> F[Verifica con criterion que de verdad mejoro]
F --> B
style A fill:#cba6f7,color:#11111b
style D fill:#a6e3a1,color:#11111b
style E fill:#fab387,color:#11111b

El flujo que ordena el nivel entero es este. Escribe claro e idiomático primero, confiando en que las abstracciones de coste cero te dan velocidad casi óptima sin esfuerzo. Perfila una carga real (lección 2) para encontrar el 3 % donde el tiempo se concentra —que casi nunca es donde tu intuición apuntaba—. Optimiza solo ese punto, con las técnicas del nivel: reducir asignaciones (lección 4), mejorar el layout (nivel 19), y solo si el perfil lo exige, SIMD (lección 3). Verifica con criterion que el cambio fue mejora y no ruido. Y vuelve a perfilar. La claridad no es enemiga de la velocidad: es su punto de partida, porque el código legible es el que puedes perfilar, entender y optimizar con cirugía en vez de con hacha.