Should proc macro crates always be compiled in release even if target crate is being compiled in debug?

[Arnavion]

I have a crate that contains 1800 structs (auto-generated bindings), each with a #[derive(Deserialize, Serialize)] attribute to generate serde impls. A debug build takes ~5m to compile this crate, while a release build takes only ~3m30s because the compiler spends much less time in expanding the serde impls, as verified by -Z time-passes and RUST_LOG=trace.

By having the code generator generate expanded impls of Deserialize and Serialize itself, these times dropped to ~3m10s and ~3m for debug and release respectively.

I know this is 1800-struct crates are few and far between, so this is an extreme edge case. But the small increases in time from each expansion add up to the ~1m30s difference between debug and release.

But from more of a technical standpoint, it seems that proc macro crates have no reason to be compiled with their dev profile since their only purpose is to be loaded by rustc itself and their expansion should always be the same. Does it make sense to always compile proc macro crates with their release profile?

[sfackler]

That seems like it would significantly increase overall build times for crates that don't have thousands of structs.

[Mark-Simulacrum]

Only "clean" builds though -- I think this is similar (but perhaps a smaller step) to #1359.

Essentially this is a superset of that where crates we build ~once we could also optimize once and result in faster code even in debug mode.

cc @nnethercote -- relates to rust-lang/rustc-perf#239

[Arnavion]

@sfackler Yes, it should absolutely be measured across all crates in crates.io or similar. Can crater be used to do this kind of experiment?

@Mark-Simulacrum Optimizing all dependencies will have a noticeable effect at runtime of the target crate, especially in terms of backtraces and general debuggability. I don't think I'd want to compile all my dependencies in release while I'm working on my crate. But proc macros only contribute at compile-time and make no difference at runtime (they're not even compiled for the target arch), so there should be no observable difference apart from compile-time in how they're compiled.

[alexcrichton]

I'm going to close this in favor of #1359 and rust-lang/rust#48683 which I believe should cover this use case

[Arnavion]

Yes, rust-lang/rust#48683 would cover this. Seems like it would be opt-in rather than automatic, but that's fine.