Perfilar: samply, flamegraphs y benchmarks estadísticos con criterion

La primera regla del rendimiento es también la más incumplida: medir, no adivinar. La intuición sobre dónde se va el tiempo de un programa es notoriamente mala —hasta los mejores ingenieros aciertan la mitad de las veces—, y optimizar por corazonada suele endurecer código que nadie ejecuta mientras el verdadero cuello de botella sigue intacto. Perfilar responde dos preguntas distintas con dos instrumentos distintos. ¿Dónde se quema el tiempo? lo contesta un perfilador de muestreo —samply, perf— que fotografía la pila cientos de veces por segundo y dibuja el resultado en un flamegraph. ¿Cuánto tarda esto, y mi cambio lo mejoró de verdad o fue ruido? lo contesta criterion, que trata cada medición como lo que es —una muestra estadística— y te da intervalos de confianza en vez de un número engañoso. Esta lección te enseña a manejar ambos y, sobre todo, a encadenarlos.

Dónde se va el tiempo: muestreo y flamegraphs

Un perfilador de muestreo no instrumenta tu código: lo interrumpe a intervalos regulares —pongamos mil veces por segundo— y anota la pila de llamadas en ese instante. Al acumular decenas de miles de muestras, las funciones donde el programa pasa más tiempo aparecen en más pilas, y esa frecuencia es el perfil. samply es la herramienta moderna y multiplataforma: perfila un binario y abre la interfaz del Firefox Profiler en el navegador.

cargo install samply
cargo build --release
samply record ./target/release/mi_programa

En Linux, perf es el estándar del sistema (perf record -g --call-graph dwarf ./bin y luego perf report), y cargo flamegraph envuelve perf o dtrace para escupir directamente un SVG. El flamegraph es la visualización canónica, y leerlo bien exige desaprender una intuición: el eje horizontal no es el tiempo, es la proporción de muestras. Cada caja es un marco de pila; su anchura es la fracción del tiempo total que se pasó ahí (sumando todas sus apariciones), y el apilamiento vertical es la profundidad de llamada. Se busca la barra ancha: la función gorda en la cima de una pila es donde arde la CPU.

[profile.release]
debug = true            # o "line-tables-only": simbolos sin inflar tanto el binario

Cuánto y con qué certeza: criterion

El flamegraph te señala dónde mirar; para saber cuánto tarda algo y si un cambio lo mejora hace falta otra cosa, porque una sola medición es ruido puro: la frecuencia de la CPU fluctúa, la caché está fría o caliente, el planificador del sistema se entromete. criterion resuelve esto tratando el tiempo como una distribución estadística. Ejecuta un calentamiento, toma cientos de muestras, aplica bootstrap para estimar la incertidumbre, y te devuelve no un número sino un intervalo de confianza. Además guarda el resultado anterior y te dice, al reejecutar, si el cambio es una mejora significativa, una regresión o está dentro del ruido.

[dev-dependencies]
criterion = { version = "0.5", features = ["html_reports"] }

[[bench]]
name = "mi_bench"
harness = false          # criterion trae su propio arnes, no el de libtest

// benches/mi_bench.rs
use criterion::{criterion_group, criterion_main, Criterion};
use std::hint::black_box;

fn fib(n: u64) -> u64 {
    if n < 2 { n } else { fib(n - 1) + fib(n - 2) }
}

fn bench_fib(c: &mut Criterion) {
    c.bench_function("fib 20", |b| b.iter(|| fib(black_box(20))));
}

criterion_group!(benches, bench_fib);
criterion_main!(benches);

Se lanza con cargo bench. Dos detalles son decisivos. El primero es black_box: envuelve la entrada para que el optimizador no pueda plegar el cálculo a una constante en tiempo de compilación —sin él, criterion mediría la nada, porque el compilador precomputaría fib(20)—. El segundo es que criterion genera un informe HTML con gráficas de la distribución en target/criterion/, donde ves la forma de la medición, no solo su media. Existe una alternativa más ligera y reciente, divan, con menos ceremonia; pero el principio es idéntico: nunca confíes en una sola cifra.

flowchart TD
A[Sospechas que algo es lento] --> B[samply o perf muestrean la pila mil veces por segundo]
B --> C[Flamegraph revela la barra ancha el punto caliente]
C --> D[criterion mide ese punto con cientos de muestras]
D --> E{El intervalo mejora de verdad}
E -->|si| F[Reperfilas el conjunto y buscas el siguiente punto]
E -->|no| G[Descartas era ruido y pruebas otra idea]
style A fill:#f38ba8,color:#11111b
style C fill:#fab387,color:#11111b
style D fill:#89b4fa,color:#11111b
style F fill:#a6e3a1,color:#11111b

La metodología: perfilar, medir, reperfilar

Los dos instrumentos no compiten: se encadenan. El flujo disciplinado empieza siempre por el perfilador de muestreo sobre una carga realista, para hallar el punto caliente real —no el que imaginas—. Solo entonces aíslas esa función en un benchmark de criterion, iteras sobre ella midiendo cada cambio contra el intervalo anterior, y cuando la has mejorado vuelves a perfilar el conjunto para confirmar que el cuello de botella se movió a otra parte. Perfilar sin medir te deja sin saber si mejoraste; medir sin perfilar te lleva a optimizar código que no importa.

Ese último es el pecado capital, el que Knuth bautizó y que la lección 5 del nivel desarrolla: la microoptimización prematura. Un microbenchmark que hace diez veces más rápida una función que consume el 1 % del tiempo total es esfuerzo tirado, porque por la ley de Amdahl la ganancia máxima del programa es ese 1 %. El benchmark aislado también miente por omisión: mide con la caché caliente y sin la contención real, así que una función que vuela en criterion puede arrastrarse en producción por fallos de caché que el microbenchmark nunca reprodujo. El perfil sobre carga real es el que manda; criterion es para afinar lo que el perfil ya señaló.