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!

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.

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.

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.