-2

We are migrating a project from Visual Studio 6 (I know) to Visual Studio 2010. We ran into quite a few problems having Visual Studio do the conversion for us automatically, so we had to do it manually.

Here are the command line options for both:

2006
/nologo /MD /W3 /GX /O2 /D "WIN32" /D "NDEBUG" /D "_WINDOWS" /D "_MBCS" /D "_USRDLL" /D "HCR_DLL_EXPORTS" /Fp"Release/hcr_dll.pch" /YX /Fo"Release/" /Fd"Release/" /FD /c 

2010
/Zi /nologo /W4 /WX- /O2 /Oy- /D "WIN32" /D "NDEBUG" /D "_WINDOWS" /D "_USRDLL" /D "HCR_DLL_EXPORTS" /D "_WINDLL" /Gm- /EHsc /MD /GS /fp:precise /Zc:wchar_t /Zc:forScope /Fp"Release\hcr_dll.pch" /Fa"Release\" /Fo"Release\" /Fd"Release\vc100.pdb" /Gd /wd"4996" /analyze- /errorReport:queue

I went through the options for both on this page. It seems the 2010 version of compilation options enables exceptions and the VC6 version does not? Maybe that is the reason? We are going to start running some benchmarks now, but there are a lot of combinations to try, and we are not very experienced with this, so if you can look at this and see the reason immediately, I will buy you a beer in heaven.

EDIT: I understand why some might not like this question. We are currently trying to isolate the problem and come up with a specific test to show the difference. This is a giant, legacy .dll, so I was hoping maybe this was just some obvious issue that an experienced eye would catch by looking at the compilation options. If not, we will keep working away trying to isolate the problem. Thanks.

EDIT2: I apologize for the nature of this question and agree that it should be closed. We fooled around with the compilation options and came up with something that actually sped up our program by about 20% when compared to VC6. I know I should have posted specific code that demonstrates this benchmark, but we are under a tight squeeze, so we are just going to use this and not look into it anymore for now. I hope to return to this issue some time, but given our schedule here, I may not get to it. For anybody who is interested, these are the options we use now.

/Z7 /nologo /W4 /WX- /O2 /Oy- /D "WIN32" /D "NDEBUG" /D "_WINDOWS" /D "_USRDLL" /D "HCR_DLL_EXPORTS" /D "_WINDLL" /Gm- /MD /GS- /fp:precise /Zc:wchar_t /Zc:forScope /Fp"Release\hcr_dll.pch" /Fa"Release\" /Fo"Release\" /Fd"Release\vc100.pdb" /Gd /wd"4996" /analyze- /errorReport:queue

This probably will not actually help anybody b/c they have no idea of what our program is doing, but I thought I would post it nonetheless. Sorry if I have caused any one to waste a significant amount of time on this.

oob
  • 1,948
  • 3
  • 26
  • 48
  • "Slower" is really not enough description to go on. – tenfour Nov 17 '11 at 16:43
  • Show us a specific block of code that you have profiled and demonstrated is slower in VS10 than it was in VS6. – John Dibling Nov 17 '11 at 16:49
  • There has been a lot of time between 1998 (VS6) and 2009 (VS2010) ... it is more of a surprise when everything still works than that something changes its speed. – PlasmaHH Nov 17 '11 at 16:49
  • @tenfour. this is a giant legacy .dll. We will try to isolate the problem, but I was thinking maybe there was something obvious about our command line options that somebody with an experienced eye might catch. – oob Nov 17 '11 at 16:54
  • @John Dibling. Good point John. We are working on this now. I've added an edit. Thanks! – oob Nov 17 '11 at 16:58
  • Closing as not a real question because the suggested issue (vs6 -> vs2010 causes "slowness") does not actually exist. When more specific data arrives, OP can submit a new more detailed question. – tenfour Nov 17 '11 at 17:16

1 Answers1

3

Per your comments, there is no basic inherent reason why code compiled in VS10 would be slower than code compiled in VS6. VS10 is, by and large, much better than VS6. the optimizer, for one thing, has evolved greatly in the past decade.

That being said, there is much that is different in the language that VS6 implemented versus the language that VS10 implements. Both are called "C++" by MicroSoft, but the fact of the matter is they aren't the same C++, and in many cases they aren't C++ at all. In particular, there was much that VS6 did that wasn't even legal C++ when the compiler was new, and much more that became invalid C++ after it was released. Consider:

for( int i = 0; i < 10; ++i )
{
/* ... */
}
cout << i;

In VC6 the above is legal, well-defined, compiles and runs as expected. But it is invalid C++ by more recent Standards.

This is just one of too many examples to enumerate. You should review the many lists of Breaking Changes that MS published for each compiler between VC6 and VC10. Here are a few in another answer I posted before:

You should review MS's lists of breaking changes when deciding if & how to undertake this project.

Breaking Changes VC 2005 - 2008

Breaking Changes in the Visual C++ 2005 Compiler

Breaking Changes in Visual C++ .NET 2003

Community
  • 1
  • 1
John Dibling
  • 99,718
  • 31
  • 186
  • 324
  • Thank you John for taking the time to post this answer. I have been reading over the Breaking Changes. – oob Nov 17 '11 at 19:09