C++ .dll natif plus lent sous Visual Studio 2010 par rapport à Visual Studio 6

Question

Nous migrons un projet de Visual Studio 6 (je sais) à Visual Studio 2010. Nous avons rencontré pas mal de problèmes en ayant Visual Studio faire la conversion pour nous automatiquement, nous avons donc dû le faire manuellement.

Voici les options de ligne de commande pour les deux:

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 

Je suis passé par les options pour les deux sur this page. Il semble que la version 2010 des options de compilation permet des exceptions et que la version VC6 ne le fait pas? Peut-être que c'est la raison? Nous allons commencer à faire des benchmarks maintenant, mais il y a beaucoup de combinaisons à essayer, et nous n'avons pas beaucoup d'expérience avec ça, donc si vous pouvez regarder ça et voir la raison immédiatement, je vais vous acheter une bière au paradis .

EDIT: Je comprends pourquoi certains pourraient ne pas aimer cette question. Nous essayons actuellement d'isoler le problème et de proposer un test spécifique pour montrer la différence. Il s'agit d'un .dll hérité géant, alors j'espérais que c'était peut-être un problème évident qu'un œil expérimenté saisirait en regardant les options de compilation. Sinon, nous continuerons à travailler en essayant d'isoler le problème. Merci.

EDIT2: Je m'excuse pour la nature de cette question et suis d'accord qu'elle devrait être fermée. Nous avons triché avec les options de compilation et avons trouvé quelque chose qui a accéléré notre programme d'environ 20% par rapport à VC6. Je sais que j'aurais dû poster un code spécifique qui démontre ce point de référence, mais nous sommes sous pression, alors nous allons juste l'utiliser et ne plus le regarder pour l'instant. J'espère revenir sur cette question un peu de temps, mais compte tenu de notre emploi du temps, je n'y arriverai peut-être pas. Pour ceux qui sont intéressés, voici les options que nous utilisons maintenant.

/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 

Cette aide ne sera probablement pas en fait personne b/c ils ont aucune idée de ce que notre programme est fait, mais je pensais que je posterais néanmoins. Désolé si j'ai fait perdre beaucoup de temps à quelqu'un.

Answer 1

Selon vos commentaires, il n'y a pas de raison intrinsèque fondamentale pour laquelle le code compilé dans VS10 serait plus lent que le code compilé dans VS6. VS10 est, en gros, beaucoup mieux que que VS6. l'optimiseur, d'une part, a beaucoup évolué au cours de la dernière décennie. Ceci étant dit, il y a beaucoup de différences dans le langage implémenté par VS6 par rapport au langage implémenté par VS10. Les deux sont appelés "C++" par MicroSoft, mais le fait est qu'ils ne sont pas le même C++, et dans la plupart des cas ils ne sont pas du tout C++. En particulier, il y avait beaucoup de choses que VS6 faisait qui n'était même pas légal en C++ quand le compilateur était nouveau, et beaucoup plus qui est devenu C++ invalide après sa sortie. Considérez:

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

Dans VC6, ce qui précède est légal, bien défini, compile et fonctionne comme prévu. Mais il est invalide C++ par des normes plus récentes.

Ceci est juste un exemple parmi tant d'autres à énumérer. Vous devriez passer en revue les nombreuses listes de modifications de rupture publiées par MS pour chaque compilateur entre VC6 et VC10. Voici quelques-unes dans another answer j'ai posté avant:

Vous devriez examiner les listes de MS de casser les changements au moment de décider si & comment entreprendre ce projet.

Breaking Changes VC 2005 - 2008

Breaking Changes in the Visual C++ 2005 Compiler

Breaking Changes in Visual C++ .NET 2003