All that being said, I don’t see much commentary on optimise(size). Does this mean the optimise(size) is rather fine? I’m considering removing optimise(no/never) from the RFC altogether, so that the attribute that really matters (the optimise(size)) can go through RFC process faster and with less bikeshedding.
Yeah, #[optimize(size)] is
much more about intent. Thinking about it a little
more though, I do have a few more questions.
When should users use it?
If someone starts with “I care about code size”, I assume the next step should generally be “so I use -C opt_level=s”, rather than “so I put #[optimize(size)]
all over my code base”. And for library maintainers starting with “my users care about code size”, “so they should use -C opt_level=s” is probably a better starting point than “so I use #[optimize(size)] for them”.
How does it interact with opt_level?
If you put #[optimize(size)] in your Rust code and then compile it with
opt_level=0, which one should win? How about opt_level=z?
Here’s a possible approach:
- Both opt_level=0 or opt_level=z override any
#[optimize(size)]
directives in the code.
-
#[optimize(size)] overrides opt_level=1, 2, or 3.
Do you want a #[optimize(speed)] too?
Similar to how you sometimes want to set opt_level=2 but override it to optsize for individual functions, sometimes you might want to do the inverse: set opt_level=s and override it to optimize for speed in individual functions.
The questions above would apply here too. Users that care about performance probably shouldn’t default to putting #[optimize(speed)] all over their codebase. And, you might want opt_level=0 to override #[optimize(speed)].
