Skip to content

enforce Optimizations when using Custom Build Configurations #1494

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

Merged
merged 2 commits into from
Jul 16, 2020

Conversation

adamsitnik
Copy link
Member

fixes #1493

cc @abelbraaksma

@adamsitnik adamsitnik added this to the v0.12.2 milestone Jun 30, 2020
@abelbraaksma
Copy link

Wow, that was fast! I wonder how that will influence the timings (things were already faster with Debug JIT, I wonder what the real improvements are).

Thanks for this!

@abelbraaksma
Copy link

If I understand this change correctly, it changes the parent scaffolding. The build settings for my own project already had this setting.

But since the scaffolded project is the one that runs, it still matters what jit is chosen, I guess.

@adamsitnik
Copy link
Member Author

Wow, that was fast!

correctness bugs are always getting top priority! I was also attending a few meetings in a row and wanted to be productive ;)

@abelbraaksma in your particular case we had two-projects:

  • the project that defined the benchmarks (Optimize set to true in .csproj)
  • the auto-generated project (Optimize not set to true for custom build configurations)

So the boilerplate code generated by BDN was not optimized, but your code has been. It's not BAD, but definitely far from perfect.

The problem would be much bigger for scenario where the project with benchmarks would reference more projects. They would all have been build for given build configuration with optimizations not enabled.

Auto-generated (Optimizations disabled) -> Benchmarks (Optimizations enabled) -> Libraries (Optimizations disabled)

The fix that I've provided passes /p:Optimize=true to MsBuild anytime we call dotnet build|publish|restore and once we have it merged, setting <Optimize>true</Optimize> won't be needed anymore in the project with benchmarks.

@abelbraaksma
Copy link

Thanks for the explanation. So seeing "RyuJIT DEBUG" does not mean a checked build of RyuJIT is used, but that the boilerplate project was built using debug settings (or at least without optimizations).

This may or may not explain that I occasionally saw very weird timings (up to 4x slower than the reference project). I also occasionally had unexpected errors when halfway the benchmark. Though often a manual clean of the bin directories solved those issues.

@AndreyAkinshin AndreyAkinshin merged commit 254da42 into master Jul 16, 2020
@AndreyAkinshin AndreyAkinshin deleted the customBuildConfiguration branch July 16, 2020 06:56
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Using WithCustomBuildConfiguration leads to always running with RyuJIT Debug
3 participants