Visual Studio 2008 C++ code slower than Visual Studio 2005

Question

 

After recompiling some of our performance critical code I've noticed that the binaries created in Release mode with Visual Studio 2008 Pro are about 5-15% slower than the exact same code compiled with Visual Studio 2005. Just creating a very simple project running a large loop passing strings I can see performance differences.

 

Is anyone else seeing this?

 

Thanks,

Dave.

Answer 1

I am experiencing the same issue with Visual Studio 2008.  I created a board game program.  Compiling with visual studio 2005 in release mode, I get great search performance; on the order of 4 million nodes per second on a Core 2 Duo.  Re-compiling the exact same source code with Visual Studio 2008 in release mode I get very dismal performance; well less than 1 million nodes per sec, or a performance drop exceeding 75%.  This is unacceptable.

Answer 2

I stand corrected... Visual Studio 2008 generates faster code.  I opened the initial solution (.sln) which was created with VS 2005 with 2008 and hit compile, thinking that all optimization settings, etc. from the 2005 environment would be on in the 2008 environment.  They weren't.  After tweaking optimization settings it spits out faster code than that of VS-2005.

Answer 3

Hi Dave,

 

Can you provide the sample code with the detailed steps to help me reproduce the performance difference between VS2005 and VS2008?

 

Thanks.

Please remember to mark the replies as answers if they help and unmark them if they provide no help.

 

Answer 4

 

After a little more investigation it appears that the vs2008 compiled binary is only slower on my AMD x2 4200 machine. On an Intel Core 2 Duo processor the vs2008 compiled binary runs faster.

 

As far as I'm aware I'm not specifying and settings that say I want to target Intel processor specifically (I'm using the CRT libraries from the x86 redist folder).

 

Any advice on how to compile a single binary that runs as fast as 2005 when run on either AMD or Intel processors?

 

Thanks,

Dave.

Answer 5

Hi,
Did anyone find the reason of slowness and how to compile for diff processors??

Answer 6

I saw a thread documenting that the VS2008 project converter fumbles the optimizer settings.  I couldn't find it back if I tried.  Better check them.

---

Hans Passant.

Answer 7

Is this problem unique to C++?  I am seeing similar performance degradation in my ASP.NET/C# app since I started using Visual Studio 2008.

---

Ray Saltrelli | Software Engineer | Mindex Technologies Inc. | Rochester, NY

Answer 8

dehjomz,

I see that you have solved the problem. Could you please describe how exactly?
My solution has been generated initially from VS 2005 SP1. It has been migrated with VS wizard to 2008 SP1. Optimization settings are all there, however I have experience at least 30% slow code in C++. Thanks.

Answer 9

 In Visual Studio 2008 SP1 (SP1 not RTM) there is a serious bug with /O2 optimization. One way this bug can be triggered is by upgrading a project from a previous version. Even though the project setting shows the release build is set to /O2, the build can be not optimized at all. To work around it you have to change the setting to no optimization, apply, and then change it back to /O2. The quick way to see if this is needed is to check whether the setting for optimization is in bold or regular - if's it's bold you're OK; if it's regular text you're not.

This bug has been reported to Microsoft by many people over the past few months via the Connect feedback site but every case has been closed by them without doing anything and for completely invalid reasons.

Answer 10

Yes. This happened exactly to me. I was upgrading from a 2005 project, the /Ob2 was beeing seen but it was not optimzing at all! You can check if it is set, looking in the .vcproj file (this ws my case) , in the configuration section you must have something like:

      <Tool Name="VCCLCompilerTool"

            Optimization="2"

....

Thanks Jon.

Answer 11

Microsoft have now closed off all the bug reports on this issue, declaring it "fixed in VS2010". Of course, that doesn't help anyone using VS2008 unless they can find a workaround...