In the build settings panel of VS2010 Pro, there is a CheckBox with the label "optimize code"... of course, I want to check it... but being unusually cautious, I asked my brother about it and he said that it is unchecked for debugging and that in C++ it can potentially do things that would break or bug the code... but he doesn't know about C#.
So my question is, can I check this box for my release build without worrying about it breaking my code? Second, if it can break code, when and why? Links to explanations welcome.
You would normally use this option in a release build. It's safe and mainstream to do so. There's no reason to be afraid of releasing code with optimizations enabled. Enabling optimization can interfere with debugging which is a good reason to disable it for debug builds.
In C# the optimization should NEVER break your code.
Instead, with optimizations turned on the compiler produces more compact CIL when translating between C# and CIL.
I observed (and frankly it's interesting!) that the C# compilers from .NET < 2.0 (1.0 and 1.1) produced as good CIL WITHOUT optimizations as later C# compilers (2.0 and later) produce WITH optimizations.
It is possible that some bugs will occur when running in release mode that do not otherwise occur. The infamous "non-volatile flag" comes to mind:
This happens because of compiler optimizations, as the flag variable gets cached by the core of thread t and thus it cannot see the updated value of flag.
In my case when I had the optimizations flag turned on it would not complete all the operations so there were measuring points missing in the final result so I simply turned the optimization flag off to fix the bug:
Thus I replaced the Parallel.Invoke call with this as well. FYI, this problem occurred using .NET Framework 4.7.
UPDATE:
OK, I've found that I was able to re-enable the optimization flag and use
Parallel.Invoke
if I remove theasync Task
from the method signature:Alternatively, I think I could use
Task.Run
for each and then a awaitTask.WhenAll(t1, t2, t3);
as explained here, but in this case I am not making explicit database calls so I don't think it applies to useTask.Run
instead ofParallel.Invoke
though this page does explain why my Parallel.Invoke was not completing: Parallel.Invoke does not wait for async methods to completeFor details, please see "Concurrency in C#" https://stephencleary.com/book/
Example wise i have a piece of code from some simulation parts of my master thesis. In which with the optimization flag turned on the code don't really break the program, but the pathfinder only performs one run and loops. (the recursive code traps itself in a loop on the pathfinder which it always breaks out of with the optimization flag turned off).
So yes it is possible for the optimization flag to make the software behave differently.
The optimizations shouldn't really break your code. There's a post here by Eric Lippert which explains what happens when you turn that flag on. The performance gain will vary from application to application, so you'll need to test it with your project to see if there are any noticeable differences (in terms of performance).