Perfiles de build: dev, release y el ajuste fino

Un perfil de compilación es una elección sobre un triángulo de tensiones: tiempo de compilación, velocidad de ejecución y tamaño del binario. No puedes maximizar los tres a la vez —optimizar más cuesta compilar más, y el binario más rápido rara vez es el más pequeño—, así que cada perfil fija un punto en esa superficie. Cargo te entrega dos institucionalizados, dev y release, que cubren el noventa por ciento de los casos, y un juego de palancas —opt-level, lto, codegen-units, panic— para moverte a cualquier otro. Saber girarlas, y saber que puedes girarlas por dependencia, es la diferencia entre aceptar los valores por defecto y esculpir el binario que necesitas.

Los cuatro perfiles y el triángulo

Cargo trae cuatro perfiles. dev gobierna cargo build; release, cargo build --release; y dos que heredan de ellos: test hereda de dev y bench hereda de release. Sus valores por defecto encarnan los dos extremos del triángulo:

[profile.dev]
opt-level = 0          # sin optimizar: compila rapido, itera rapido
debug = true           # simbolos completos para el depurador
overflow-checks = true # panic si un entero desborda

[profile.release]
opt-level = 3          # optimizacion agresiva
debug = false
overflow-checks = false

dev prioriza el bucle de feedback: compilación veloz, aritmética comprobada, símbolos para depurar. release prioriza el binario final: código rápido, sin comprobaciones de desbordamiento, sin símbolos. Elegir perfil es elegir en qué vértice del triángulo quieres estar hoy.

Las palancas finas

Más allá de esos dos puntos, cada palanca mueve una tensión concreta:

• opt-level acepta 0, 1, 2, 3 y también "s" y "z", que optimizan por tamaño en vez de por velocidad ("z" es el más agresivo con el tamaño, hasta desactivar el desenrollado de bucles).
• lto —link-time optimization— habilita el inlining entre crates. "thin" da casi todo el beneficio a bajo coste; "fat" (o true) exprime más a cambio de una compilación mucho más lenta.
• codegen-units parte el crate en unidades que se compilan en paralelo (256 en dev, 16 en release). Bajarlo a 1 da al optimizador visión global del crate —mejor código— renunciando al paralelismo interno.
• panic por defecto es "unwind" (desenrolla la pila liberando recursos). Ponerlo en "abort" elimina las tablas de desenrollado —binario más pequeño y algo más rápido— pero aborta el proceso en un panic, y anula catch_unwind.
• strip con "symbols" elimina la tabla de símbolos, recortando el tamaño del binario en disco.

Combinadas, estas palancas producen recetas con intención. La del binario mínimo, típica para WebAssembly o distribución embebida, sacrifica velocidad de compilación y capacidad de desenrollado por cada byte:

[profile.release]
opt-level = "z"        # optimiza por tamano
lto = true             # inlining entre crates
codegen-units = 1      # una unidad: mejor optimizacion global
panic = "abort"        # sin tablas de desenrollado
strip = true           # elimina simbolos

Overrides por paquete y perfiles a medida

La palanca más sutil es que la optimización no tiene por qué ser uniforme. Con [profile.<perfil>.package.<crate>] ajustas el nivel de una sola dependencia. El caso de oro: estás en dev para iterar rápido, pero una dependencia numérica —descompresión, imagen, criptografía— corre tan lenta sin optimizar que hace inusable tu programa. La optimizas a ella, y solo a ella:

# En dev, tu crate sigue a opt-level 0 (recompila rapido),
# pero esta dependencia pesada se compila optimizada:
[profile.dev.package.image]
opt-level = 3

# Un perfil propio que hereda de release y afina mas:
[profile.release-fast]
inherits = "release"
lto = "fat"
codegen-units = 1

Un perfil personalizado se invoca con cargo build --profile release-fast. Y hay dos overrides más que resuelven molestias reales del día a día:

# Optimiza los build scripts y las macros procedurales
# aunque tu crate siga sin optimizar:
[profile.dev.build-override]
opt-level = 3

# Optimiza TODAS las dependencias en dev, pero no tu propio crate:
[profile.dev.package."*"]
opt-level = 2

El comodín "*" alcanza a la vez a todas las dependencias: es la receta clásica para que un proyecto con muchas dependencias pesadas siga siendo usable en dev sin renunciar a recompilar tu propio código en un parpadeo.

flowchart TD
DEV[perfil dev] --> TEST[perfil test hereda dev]
REL[perfil release] --> BENCH[perfil bench hereda release]
REL --> FAST[perfil propio hereda release]
DEV --> OV[override por paquete: una dependencia optimizada]
style DEV fill:#89b4fa,color:#11111b
style REL fill:#a6e3a1,color:#11111b
style OV fill:#f9e2af,color:#11111b