-
-
Notifications
You must be signed in to change notification settings - Fork 401
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
Added more build profiles #290
Conversation
This will add build profiles for benchmarks and tests. It will also add a thin optimization layer to development builds, and make sure that benchmarks are run with the same build profiles as the release builds.
I modified the configuration to only show the changed options from the defaults, and to add some comments on why the defaults were changed. |
overflow-checks = true | ||
panic = 'unwind' | ||
# Enables thin local LTO and some optimizations. | ||
opt-level = 1 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I’m not sure for dev we want any optimisations, also setting 1 turns off the debug asserts which I think we’re using to get better feedback if something is wrong on dev
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I was trying to find where it said that this would disable debug assertions, but I couldn't find it.
Let me know if this is good to go, @jasonwilliams |
I will need to test this with the debugger, having an opt-level of 1 might remove some of the information for the LLDB debugger to show properly |
Testing this today with the debugger, i can still see all the values i had before, so a level of 1 seems ok, but we still have the debug_assert issue https://doc.rust-lang.org/cargo/reference/profiles.html |
If I understand the reference properly, the I just checked by adding a This small optimization level is very fast at compile time, but gives a ton of performance improvements that will be interesting when running a lot of tests, or running example workloads that take long to execute. |
Let me know, @jasonwilliams if this is good to go, or if we don't want the optimizations on debug/test builds :) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this is good to go!
This will add build profiles for benchmarks and tests. It will also add a thin optimization layer to development builds, and make sure that benchmarks are run with the same build profiles as the release builds.