Los perfiles de compilación

Los dos perfiles

La fila de las comprobaciones de desbordamiento merece un aviso: en desarrollo, una suma de enteros que se pasa del rango produce un pánico inmediato; en publicación, por defecto, da la vuelta en silencio. Es una diferencia de comportamiento real entre los dos modos, y si tu core hace aritmética con datos de fuera, conviene dejarlas activas también al publicar. Es una línea.

Los cuatro ajustes que recortan

Van en el Cargo.toml, en la sección del perfil de publicación:

[profile.release]codegen-units = 1     # una sola unidad: el compilador ve el programa enterolto = true            # optimización durante el enlazado, entre módulosopt-level = "s"       # optimizar por tamaño en vez de por velocidadstrip = true          # quitar los símbolos del binario final

Qué hace cada uno y qué cuesta:

El que cambia el comportamiento

Hay un quinto ajuste que aparece en todas las listas de «reduce tu binario» y que no es una optimización:

panic = "abort"

Por defecto, cuando un hilo entra en pánico en Rust, se desenrolla la pila: se ejecutan los destructores, se liberan los recursos, y el pánico puede capturarse en el límite del hilo. Con este ajuste, un pánico termina el proceso inmediatamente. Se ahorra el código de desenrollado, que no es poco, y se pierden tres cosas:

• Los destructores no corren. Un fichero a medio escribir se queda a medias, una transacción abierta se queda abierta. Lo que tu código hiciera al limpiar, no se hace.
• Un pánico en un comando se lleva la aplicación entera. Sin este ajuste, el framework puede contener un pánico dentro de la llamada y devolver un error al frontend; con él, la ventana desaparece.
• Las herramientas que capturan pánicos dejan de funcionar.

Para una aplicación de escritorio que tiene datos del usuario abiertos, eso es una elección seria. La recomendación de este track: no lo actives salvo que hayas medido que el tamaño te importa más que la posibilidad de terminar de escribir un fichero. Y si lo activas, que sea una decisión escrita, no una línea copiada de una lista.

Medir, no suponer

Los cuatro ajustes tienen efectos muy distintos según el proyecto, así que la forma correcta es medir el tuyo:

# el tamaño del binario, antes y después de cada ajustels -lh src-tauri/target/release/mi-app# y de dónde sale el peso, dependencia por dependenciacargo install cargo-bloat && cargo bloat --release --crates

La herramienta de análisis suele dar la sorpresa: en muchos proyectos, la mayor parte del binario no es tu código ni el framework, sino una dependencia concreta que alguien añadió para algo pequeño. Quitar esa dependencia recorta más que los cuatro ajustes juntos, y no cuesta nada en tiempo de compilación ni en comportamiento. El nivel 56 lo trata a fondo.