Macro-Generated Binary Sizing

In this lesson, you will learn how macro-generated code impacts your final binary footprint and how to prune unnecessary bloat in memory-constrained environments.

When you use procedural macros to generate boilerplate—such as serialization logic or state machine transitions—it is easy to forget that every generated line of code is compiled into your machine executable. In resource-constrained systems, such as embedded targets or WASM modules, "generative convenience" can quickly lead to binary bloat that exceeds your storage limits.

The Cost of Monomorphization

Macros often generate repetitive, specialized code for every type they touch. If a macro creates a unique match arm or a full trait implementation for every struct in your codebase, the compiler performs extensive monomorphization. This results in the same machine instructions being duplicated across the binary.

Consider a macro that generates a custom to_json method for multiple types:

// Macro generates this for 50 different structs:
fn to_json(&self) -> String {
    let mut s = String::from("{");
    // ... complex string concatenation logic ...
    s.push('}');
    s
}

If the macro embeds complex logic rather than calling a shared function, the compiler sees 50 distinct, large functions. The instruction cache will thrash, and your binary size will skyrocket.

Strategies for Optimization

To keep the footprint lean, apply these two techniques when writing your macros:

1. Extract to Shared Functions: Instead of generating the entire implementation inside the macro, generate a call to a generic, non-inlined function in a common crate. This ensures the "heavy lifting" logic exists in the binary only once.
2. Use #[inline(never)] sparingly: If a macro generates identical logic across many types, forcing the compiler to keep that logic as a shared function (or using a #[inline(never)] attribute on the helper) prevents code duplication.
3. Inspect with cargo-bloat: Always run cargo bloat --release on your target. Look for large generated functions; if you see a repetitive pattern, it’s a sign your macro is creating "code smog."

Key Takeaway: Macros should act as a thin bridge to shared library code rather than embedding large, repeated logic blocks directly into the call site.