I believe there are two use cases currently covered by the "release" profile: actual release builds and "formal" benchmarking; local development, testing and benchmarking with optimizations.
For the former it is appropriate to turn on all optimizations (e.g. full LTO, no incremental, 1 codegen unit) and turn off anything that hinders optimization.
For the latter I believe it is acceptable to lose a small amount of performance for the sake of compile times, as long as the performance remains consistent across builds. This profile could e.g. use incremental compilation, multiple codegen units, opt-level 2, no LTO. It would still be fast, just not as fast as an aggressively optimized release build.
The first profile is a "real release" profile, the second is a "dev optimized" profile. For the sake of maintaining existing workflows the "dev optimized" would probably be called "release", so that developers can continue using the "--release" flag. The "real release" profile could be called perhaps "real-release" and it would be acceptable for the release build machines to take extra steps to enable it.
The big problem here is that cargo doesn't support custom profiles. There's an issue open for it rust-lang/cargo#2007 but it's reportedly a long way from being implemented.
Related discussion here rust-lang/rust#47745 (comment) along with some suggestions.
It looks like the smartest way to do this currently is with the nigthly-only cargo config profiles. We could throw a config file into e.g the etc/ directory where cargo won't pick it up by default, and have the release builders invoke cargo with that config overriding the "release" profile.
cc @zhouqiang-cl re the impact on the release builders. Any comments or suggestions welcome.
Edit: next steps outlined in #4189 (comment)
I believe there are two use cases currently covered by the "release" profile: actual release builds and "formal" benchmarking; local development, testing and benchmarking with optimizations.
For the former it is appropriate to turn on all optimizations (e.g. full LTO, no incremental, 1 codegen unit) and turn off anything that hinders optimization.
For the latter I believe it is acceptable to lose a small amount of performance for the sake of compile times, as long as the performance remains consistent across builds. This profile could e.g. use incremental compilation, multiple codegen units, opt-level 2, no LTO. It would still be fast, just not as fast as an aggressively optimized release build.
The first profile is a "real release" profile, the second is a "dev optimized" profile. For the sake of maintaining existing workflows the "dev optimized" would probably be called "release", so that developers can continue using the "--release" flag. The "real release" profile could be called perhaps "real-release" and it would be acceptable for the release build machines to take extra steps to enable it.
The big problem here is that cargo doesn't support custom profiles. There's an issue open for it rust-lang/cargo#2007 but it's reportedly a long way from being implemented.
Related discussion here rust-lang/rust#47745 (comment) along with some suggestions.
It looks like the smartest way to do this currently is with the nigthly-only cargo config profiles. We could throw a config file into e.g the
etc/directory where cargo won't pick it up by default, and have the release builders invoke cargo with that config overriding the "release" profile.cc @zhouqiang-cl re the impact on the release builders. Any comments or suggestions welcome.
Edit: next steps outlined in #4189 (comment)