Remove generated [profile.release] from new projects
#369
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This commit effectively reverts bytecodealliance#289 and removes the generated `[profile.release]` section from `Cargo.toml` when executing `cargo component new`. The PR mentions that a default release build decreases from 1.6M to 52KB and that was likely due to stripping DWARF debugging information rather than many of the other settings configured. Nowadays for example a default release build (with no extra configuration and no `profile.release`) is around 50KB because rustc/cargo have started stripping debuginfo by default in release mode. That means that the original motivation is still solved, the "default" build is not an alarmingly large 1.6M. Otherwise the various settings configured here can have negative effects which aren't always easy to debug if you're not familiar with them, for example: * `lto = true` and `codegen-units = 1` can massively increase the time needed for a build. This can be surprising to newcomers who may have heard about Rust compile times being bad but this is an order of magnitude worse than the default settings. While these two options are good rules-of-thumb for a minimally-sized build not everyone falls into the category of needing a minimally sized build, and users can always configure this themselves. * `debug = false` is not necessary as it's already the default of the `profile.release` in Cargo. * `strip = true` is no longer necessary in recent versions of rustc/Cargo because this is done by default for debuginfo. This is otherwise somewhat harmful as it strips the `name` custom section which hinders any after-the-fact analysis of a binary because there is no symbol information to profile with, for example. * `opt-level = "s"` is not universally smaller than the default `opt-level = "3"` and it can also perform significantly worse. An example component I was working with today had a 100% slowdown using `opt-level = "s"` relative to `opt-level = "3"`. Overall I think it's best to inherit Cargo's and Rust's defaults for these settings by default. There's no one-size-fits-all for all projects which is why Cargo allows configuring things, but for a template I think it's best to inherit default settings since that'll ideally cause the least surprise for users who aren't otherwise familiar with these settings.
calvinrp
approved these changes
Jan 15, 2025
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This commit effectively reverts #289 and removes the generated
[profile.release]section fromCargo.tomlwhen executingcargo component new. The PR mentions that a default release build decreases from 1.6M to 52KB and that was likely due to stripping DWARF debugging information rather than many of the other settings configured. Nowadays for example a default release build (with no extra configuration and noprofile.release) is around 50KB because rustc/cargo have started stripping debuginfo by default in release mode. That means that the original motivation is still solved, the "default" build is not an alarmingly large 1.6M.Otherwise the various settings configured here can have negative effects which aren't always easy to debug if you're not familiar with them, for example:
lto = trueandcodegen-units = 1can massively increase the time needed for a build. This can be surprising to newcomers who may have heard about Rust compile times being bad but this is an order of magnitude worse than the default settings. While these two options are good rules-of-thumb for a minimally-sized build not everyone falls into the category of needing a minimally sized build, and users can always configure this themselves.debug = falseis not necessary as it's already the default of theprofile.releasein Cargo.strip = trueis no longer necessary in recent versions of rustc/Cargo because this is done by default for debuginfo. This is otherwise somewhat harmful as it strips thenamecustom section which hinders any after-the-fact analysis of a binary because there is no symbol information to profile with, for example.opt-level = "s"is not universally smaller than the defaultopt-level = "3"and it can also perform significantly worse. An example component I was working with today had a 100% slowdown usingopt-level = "s"relative toopt-level = "3".Overall I think it's best to inherit Cargo's and Rust's defaults for these settings by default. There's no one-size-fits-all for all projects which is why Cargo allows configuring things, but for a template I think it's best to inherit default settings since that'll ideally cause the least surprise for users who aren't otherwise familiar with these settings.