Release Build Optimization Silently Disabled In Visual Studio 2008 SP1 RRS feed

  • General discussion

  • In November I filed a bug report on Connect (ID 383764) about a serious problem with optimization on Visual Studio 2008 SP1. Despite two further attempts to bring this to Microsoft's attention via Connect it has apparently been completely ignored (not even a comment from the triage team). Because this bug has potentially widespread and serious consequences I want to publicise it here:

    The default behavior of Visual Studio 2008 SP1 is for the project properties for a release build to show that /O2 optimization is turned on, but the /O2 flag is not passed to the compiler and the build is unoptimized, with a significant degradation of the performance of the resulting executable. It is very hard to notice that this has occured unless you inspect the actual compiler flags used, or analyze the assembly code generated.

    If the Optimization field in the Optimization page of the C/C++ project shows "Maximize Speed (/O2)" unbolded (ie it is using the project defaults) then optimization is, in fact, turned off. You need to manually change it to something else and then back to /O2 (so that it shows up in bold) before the optimization setting is used.

    If you create a new project in Visual Studio 2008 SP1 the project uses explicit rather than default optimization settings and this problem does not arise. However, if you upgrade a project from previous releases of Visual Studio or use the <inherit from parent or project defaults> option then you're in trouble.
    Tuesday, January 6, 2009 7:12 PM

All replies

  • Yes, the VS2008 project converter is broken.  There are several threads in this forum that discusses this problem.  Thanks for your feedback.
    Hans Passant.
    Wednesday, January 7, 2009 1:40 AM
  • Respectfully, no, it's not the project converter. Changing the project converter will just mask the bug, which is that the handling of defaults is broken in Visual Studio 2008 SP1 (the user interface interprets default as one setting, but the build engine interprets it as another). You can trigger this bug in an unconverted 2008 project by changing the optimization setting back to default by using <inherit from parent or project defaults>.
    Wednesday, January 7, 2009 7:46 PM
  • Denying this problem won't get it fixed. I'm reluctantly beginning the switch from VC6 to VC2008 and ran into it on my programs. These are pure, unmanaged/native Win32 apps. I copied the just the source code of one of my apps to a new directory (none of the VC6 project files), created a new VC2008 "Project from existing code", then compiled a Release version. It had the /O2 optimization setting. I saw a 50% performance hit in the heavy number crunching section of my program. Execution times were:

    6.609 seconds in VS2008
    3.266 seconds in VC6

    Absolutely horrible performance. I was about to toss VS2008 into the trash until I found this post on the forums. I did as the OP suggested and switched the optimization setting from /O2 to /Od to /Ox, clicking apply each time. I cleaned and rebuilt the app. VS2008 improved quite a bit but still lagged significantly behind VC6:

    4.359 seconds in VS2008  (4.468 with /O2)
    3.266 seconds in VC6

    Finally, I noticed all the posts about FP performance and changed from /fp:precise to /fp:fast.

    2.828 seconds in VS2008

    Of course, I'm concerned about the implications of the /fp:fast optimizations on my program's output. I don't believe that my algorithms are sensitive to the precision issues. Is there a combination of VS2008 floating point settings that make it match (or come very close) to VC6's floating point behavior?


    Monday, February 23, 2009 1:09 AM
  • Do we have any updates from microsoft on this yet ?
    Thursday, April 23, 2009 9:33 AM
  • Microsoft have:

    1) Declared that it doesn't happen in Visual Studio 2010, and therefore it's fixed.

    2) Closed without comment my active bug report.

    You can draw your own conclusions about how seriously they take this problem...
    Thursday, April 23, 2009 8:11 PM