Converting C++ Project From 2005 to 2008 Invisibly Disables Optimization For Release Build - by Jon Baggott

Status : 

  Fixed<br /><br />
		This item has been fixed in the current or upcoming version of this product.<br /><br />
		A more detailed explanation for the resolution of this particular item may have been provided in the comments section.

Sign in
to vote
ID 383764 Comments
Status Closed Workarounds
Type Bug Repros 12
Opened 11/24/2008 3:48:08 PM
Access Restriction Public


Converting a C++ project from Visual Studio 2005 invisibly turns off optimization for the release build. The optimization page of the project properties shows that /O2 is turned on, but the /O2 flag is not passed to the compiler and an unoptimized build results.

This appears to be related to bug 330854 which was closed as fixed in SP1, but now seems to be a symptom of a much more serious underlying problem.

Viewing the 2005 and 2008 .vcproj files, it appears that 2005 left the Optimization setting in VCCLCompilerTool blank for the Release build, and both the property page GUI and the compiler flag generation code interpreted blank as /O2. The conversion to 2008 leaves it blank, but the 2008 property page GUI interprets blank as /O2 and the compiler flag generation code interprets blank as no optimization flag, which is equivalent to /Od.

The workaround is to change the optimization from /O2 to /O1 and back to /O2. This causes an explicit Optimization setting to be written to the .vcproj file.

This bug has potentially massive implications. It's likely that most projects (world wide) converted to 2008 are no longer optimized and no-one realizes this. I only came across it by accident when viewing the generated assembly code for one of my projects and noticed that the supposedly optimized code was very inefficient. Fixing this gave me a 35% performance improvement in a time-critical application.


I just discovered that this bug is worse than I originally thought. You can trigger it with a project that was created in VS 2008, not just one than was converted from 2005. All you have to do is to go to the compiler optimization page for the Release build and select  <inherit from parent or project defaults>. On hitting apply, the setting will change from "Maximize Speed (/O2)" in bold to "Maximize Speed (/O2)" unbolded, and the /O2 compiler flag will be deleted.

Basically, if the GUI says Maximize Speed /O2 unbolded, it's lying and the build is unoptimized.
Sign in to post a comment.
Posted by Bulat Sagdullin on 6/15/2010 at 3:35 AM
>For VS2008, unfortunately, I can only provide a workaround
For my view it is too important to provide a workaround only. Please, create a fix for VS2008!
Posted by gast128 on 3/26/2010 at 5:05 AM

indeed we experienced the same problem. We converted our solution form 2003 to 2008 sp1 and lost the optimizations. After we released, we accidentally noticed that the optimziations were not applied. I think Microsoft should have given more attention to this problem, instead of leaving it here @ It is a shame that our customers had bad performance due to this issue.

Also we are not happy with this iterator debugging in release mode, since it does make a performance difference (especially it blocks some optimzations). Luckily it seems that in 2010 this is turned off by defualt for relase builds.
Posted by Microsoft on 8/10/2009 at 10:41 AM
Hello Jon,

Sorry it took us this long to revisit this bug. You are correct that this bug does repro in VS2008 SP1. It turns out that we had a small glitch and our complete fix didn't make it in SP1 - the only difference from VS2008 RTM is that now we show /O2 as the default value even if this doesn't end up as the default value when invoking the compiler.

We addressed this issue in VS2010 and as you migrate from VS2005 or VS2008, /O2 will correctly get passed to the compiler even if not explicitly set for the Release configurations.

For VS2008, unfortunately, I can only provide a workaround: to explicitly set /O2 in the Release configuration (make sure it's marked as bold i.e is not inheriting from the defaults.) Hope this is not a blocking issue.

Apologies for the long wait again. Hope that you also have a chance to try out VS2010 where we made significant improvements to our build system. More details here:

Marian Luparu
Project & Build
Posted by Ruud van Gaal on 7/7/2009 at 8:38 AM
Funny that the case was closed; I just tried a converted project from VS2005 in VS2008SP1.
Indeed, the project properties stated 'Maximize speed (/O2)' but the commandline didn't show any optimization flag.
Switching to /O1, Apply and /O2, Apply did get back the optimize flag.
Quite a biggy.
Posted by Jon Baggott on 5/1/2009 at 4:59 PM
After I reopened this case, Microsoft just closed it again without comment. Although it's marked as fixed, apparently that just means that it doesn't happen in VS2010 - VS2008 SP1 is still broken and Microsoft just don't care...
Posted by Jon Baggott on 1/12/2009 at 12:21 PM
Please take the time to actually read the report. After all, I submitted it in November last year and this is the first indication that anyone at Microsoft has actually looked at it.

I _am_ using Visual Studio SP1. Please read the Version field of this report. This bug is fully reproducible in SP1. I have checked it on multiple installations of Visual Studio SP1. There are multiple validations here, and even another bug report on the same issue (389232) although it looks like that bug report received the lack of care in its handling.

Your workarounds do not work. You cannot just set /O2 because the UI reports that /O2 is already set. You need to change it away from /O2 and back again. Again please read what I wrote above. If you create a property sheet you will see that /O2 is apparently already set. Of course because of this bug it isn't. Again, you need to change it away from /O2 and back before it takes effect. In any case property sheets are unacceptable because they cannot be placed under source control correctly (you can find bug reports and knowledge base articles on this if you look).

Workarounds are irrelevent as the real problem is that although the effect of this bug on the performance of the release build is serious it's really hard to tell that there's an actual problem unless you are aware of this bug, thus many commercial applications may be unknowingly shipped with inferior performance. I have already fixed all my projects by hand. How many other developers are you condeming to ship inferior products because you won't take this seriously?

if the known problem you're referring to is 330854 then the "fix" supposedly made is likely what has created this whole problem.

Over the months since I filed this report I have found a simpler way to repro it:

In Visual Studio 2008 SP1 (note: SP1) create a Win32 console project. Go to the optimization settings for the Release build and select <Inherit from parent or project defaults>. That's it.
Posted by Microsoft on 1/10/2009 at 1:07 AM
Hello Jon,

Thank you for taking the time to report this issue. This is a known bug in VC 2008 that was fixed in Service Pack 1. Please upgrade to the latest SP.

Alternatively, you can explicitly set /O2 for the Release configurations for your projects either by:

1) setting the solution configuration to be Release, multi-select all projects, right click, bring up the properties and set /O2 setting (C/C++ Compiler > Optimizations > Optimization = Maximize Speed).
2) In Property Manager, create a new property sheet that sets Optimization = Maximize Speed, multi-select all Release configurations of all your projects, right click, Add Existing Property Sheet, and add the property sheet just created.

Hope this helps,
Marian Luparu
Visual C++ IDE