Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Explain better for speed at runtime #12

Closed
frederikhors opened this issue Mar 23, 2020 · 3 comments
Closed

Explain better for speed at runtime #12

frederikhors opened this issue Mar 23, 2020 · 3 comments

Comments

@frederikhors
Copy link

frederikhors commented Mar 23, 2020

I read both:

What I don't understand is which speed gain I'm changing if I use:

[profile.release]
opt-level = "z"

instead of:

[profile.release]
opt-level = 3
  • Is it right that today opt-level = 3 is the best setting (for opt-level section) for runtime speed?

  • If I instead use opt-level = "z" I'm decreasing runtime performance, right?

I'm not interested in building/compiling speed.

@MartinKavik
Copy link

MartinKavik commented Mar 23, 2020

My experience with these options as a Seed maintainer - some algorithms with s/z can be almost 2x slower, but the app can be also 2x smaller (vs 3).
So it really depends on the specific use-case - you should write at least some benchmarks and try multiple options.

@johnthagen
Copy link
Owner

@frederikhors This repo is concerned with helping Rust developers generate the smallest possible binary size at the expense of all else. Many of the recommendations in this repo would not make sense unless you were trying to optimize soley for size.

For what the opt-level's specifically do, I do agree that the cargo docs could be improved but I suggest that an issue be opened in that repo to request. That question is mostly for rustc / LLVM.

@frederikhors
Copy link
Author

@johnthagen rust-lang/cargo#8031

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants