Cargo.toml directive to declare default optimization level when built as a build-dependency

[joshtriplett]

(Filing this issue based on discussion in the Cargo team meeting today.)

Describe the problem you are trying to solve
I like the build-time improvements provided by explicitly not optimizing build-dependencies. I'd like the ecosystem to be able to gain those improvements by default with less manual declaration.

Describe the solution you'd like
I would propose an option in the Cargo.toml of a crate that can either say "don't bother optimizing me if I'm just a build-dependency, I probably won't benefit from it" or "please optimize me even if I'm just a build-dependency" (which would optimize it even in debug mode). The former would work well for proc-macro crates that just do a simple derive, where the time spent optimizing would never get paid off when run at build time. The latter would work well for certain types of "generator" crates like phf, where optimization is incredibly important for the performance of build-time table generation, and optimization doesn't take long.

We could then use that as the default optimization level when a crate is built as a build-dependency, with higher-level crates able to explicitly override those defaults and declare how they want their build-dependencies optimized.

[est31]

For crates like lewton or image-rs, I want the same feature, just for use as a normal dependency (instead of build dependency). Such crates are rather slow without optimizations turned on, but expose low-generics APIs so their performance relevant code is compiled directly inside the crate.

Link to further discussion: rust-lang/rust#48683 (comment)

Another link: rust-lang/rfcs#2282 (comment)

[joshtriplett]

On Sat, Feb 29, 2020 at 11:48:16AM -0800, est31 wrote: For crates like lewton or image-rs, I want the same feature, just for use as a normal dependency (instead of build dependency). Such crates are rather slow without optimizations turned on, but expose low-generics APIs so their performance relevant code is compiled directly inside the crate.

Not a bad idea.

[est31]

Issue for that has been created since: #8501

[epage]

We have build-override and overrides.

For myself,. I don't know if I'd trust a dependency to correctly identify its optimizations for my build when I build on my system, for my use cases. Seems like doing this at the workspace level would be the best route.

@joshtriplett thoughts?

[joshtriplett]

@epage I would trust a dependency to provide a reasonable default that I can still override. I think it would make sense to trust information from dependencies about the usefulness of optimization when something is only a build dependency, use that as the default optimization level, and still let the top-level crate have full control via overrides.

[est31]

Yeah the example I brought up above is that of a decoder crate where users sent me complaints on how the original C impl is so much faster (they don't realize that the Rust impl is only fast if optimizations are turned on).

Another example I ran into is that of a crate that does RSA key generation, and where the effort to generate one RSA key takes longer than to optimize+compile the RSA key generator crate. Both such crates can recommend to their users to add a pofile override to that specific crate, but that is less "automatic" than having the library be able to set the default.

I do think that profile overrides should be applied after these library-set defaults, so the final say should always be with the leaf crate/workspace. I think this would sufficiently address the concern of @epage that there might be a high diversity of use cases.

[epage]

From sqlx

Compile-time verified queries do quite a bit of work at compile time. Incremental actions like cargo check and cargo build can be significantly faster when using an optimized build by putting the following in your Cargo.toml (More information in the Profiles section of The Cargo Book)

[profile.dev.package.sqlx-macros]
opt-level = 3

It sounds like this would be a way to pick this up automatically.

If we add a profile setting for mir-only rlibs, windows-sys and aws-sdk would be good candidates for this.