Visual Studio 2010生成的可执行文件大小较大

Question

Visual Studio 2010生成的可执行文件大小较大

visual-studio-2010sizeexecutable

9

我有一个用Visual Studio 6.0编写的C++应用程序。该应用程序是标准且原始的Win32 API，没有MFC（*编辑2），没有.NET，静态链接，多线程可执行文件。

我已经迁移到了所有版本的Visual Studio直到2010年（今天），并且从来没有遇到过任何问题，但现在出现了问题：

它使用VS2010编译和运行完美，但生成的可执行文件大小增加了四倍！

我尝试了我知道的所有选项（优化，删除调试信息等），但没有结果。尽管我对VS2010还不熟悉，但我对Visual Studio并不陌生。

有人遇到过这个问题吗？再次强调：我没有使用任何框架，这是一个原始的、静态链接的Win32应用程序，没有DLL、ODBC、网络、.NET。

希望再次看到我的可执行文件变小，感谢您的任何建议。

编辑1：原始大小=626KB（VS6.0、VS2008）膨胀大小=2.013KB（VS2010）

编辑2：经过一些研究和转储，我发现了对MFC的隐藏引用。最初我说它没有使用MFC，但实际上使用了。

- Migs

1

这可能是静态链接或者是在VS2010中更改了链接器设置以生成更大的部分，以便更好地缓存或其他一些原因。我们在这里谈论的是什么数量级 - 4K到16K？64K到256K？1MB到4MB？ - Rup

我已经编辑了问题，包括样本大小，在我的所有应用程序中都会出现这种情况。 - Migs

1

它确切是3.21，但会有所变化，在某些项目中差异较大，在某些项目中较小。不，我是在一台带有Win7的64位机器上进行开发，但生成的可执行文件必须是32位（这是一个项目要求）。 - Migs

1

我认为在转换解决方案时，Visual Studio可能已经添加了一些引用。我这样认为的原因是：http://connect.microsoft.com/VisualStudio/feedback/details/469785/mfc-of-vs2010-generate-a-very-large-exe-file http://social.msdn.microsoft.com/Forums/is/vcmfcatl/thread/fcf7fa2c-5263-4bfe-a352-a75485ac6cd2 - Migs

1

dumpbin会告诉你有关各种依赖项和段大小的信息。 - Ritch Melton

显示剩余3条评论

5个回答

2

如果您正在使用静态链接，我建议在命令行编译时使用链接器开关，语法如下：

cl /Ox [您的C++源文件] [所需库（如果有）] [所需资源文件（如果有）] /link /FILEALIGN:512 /OPT:REF /OPT:ICF /INCREMENTAL:NO

如果您在Visual Studio IDE中构建，请通过菜单选择项目属性来检查链接器设置。在配置中，选择发布版本，然后单击左侧窗格上的链接器设置，这将显示当前默认设置的链接器设置对应的配置列表。

在链接器下的命令行中，在附加选项条目中指定选项/FILEALIGN:512，然后单击应用按钮。在链接器的常规选项中，通过选择No(/INCREMENTAL:NO )来禁用增量链接。在链接器的调试选项中，选择No以生成调试信息。对于链接器优化，您可以在引用中选择消除未引用的数据(/OPT:REF)，在启用COMDAT折叠中选择删除冗余的COMDATs(/OPT:ICF)。

对于编译器优化，请确保选择了发布配置，在左侧窗格的C/C++树视图上单击优化，选择完全优化(/Ox)。在C/C++的常规设置中，选择禁用调试信息格式。

不要忘记为您进行的每个更改单击应用按钮。

希望我提到的所有内容对您有所帮助，所有这些都适用于Visual C++ 2005和2008，但希望它也适用于Visual C++ 2010，如果不是，请检查您的Visual C++ 2010安装包中附带的文档。

- NEL

1

这是因为在VS2010中，微软添加了允许在对话框窗口中使用HTML组件的功能，因此即使您不使用它，也会拉入一堆东西并链接起来，而优化、选项和删除未引用的代码都无法帮助。没有一种“好”的方法可以删除代码，但有一些被修改过的方法。我们仍然在VS2008上编译我们的大小关键的内容，因为这个原因。顺便说一句，我们的非GUI代码实际上编译得更小，就这样吧。希望微软能在修复/补丁中提供这个选项，这样我就可以在VS2010上完成所有工作，但我不抱太大希望...

- mark

1

你有没有把默认的平台目标设置为“Any CPU”？如果是这样，请将其更改为x86，以便只针对32位代码进行编译。我猜这将占据大部分差异。其余的差异可能在于编译器优化方面（更积极的循环展开等，其中大小已被换成速度，因为RAM很便宜）。我相信所有细粒度的优化仍然可以从命令行中使用，但许多选项已经被隐藏在UI选项面板中。

- iisystems

2

此设置适用于.NET项目，而不适用于所质疑的问题（本地编译）的情况。 - CharlesB

不，我也试过了。问题肯定是我上面所评论的90%：在迁移项目时，MFC又回来了，但现在我没有时间检查具体是在哪里。一旦我有空我就会检查并发布最终结论。 - Migs

1

请参考有没有用于追踪C++中膨胀的工具？ - 文章中描述了一些分析可执行文件大小的技术。一旦你对VC 6和VS 2010输出进行了分析，希望你能找到一些有用的东西。

在从VC 6移植到某个Visual Studio版本时，有一个特别的陷阱：一些优化选项的含义已经改变，我在VC 6项目中使用的值不再受支持，结果由VS生成的exe根本没有被优化，导致可执行文件膨胀和性能缓慢。请检查您的优化设置，在属性/C/C++/优化中确保开启了优化/Ox、/O2或/O1。

- Suma

网页内容由stack overflow 提供, 点击上面的

可以查看英文原文，
原文链接

- Helge Klein · Accepted Answer

增大的大小可能是由于对MFC的更改造成的。这里有一个解释，这里是同一作者的一个解决方法，可以将可执行文件的大小降回到与2008相当的区域。然而，该解决方法涉及到编辑MFC源文件的副本，不是每个人都能接受的过程，并且在每次更新后（例如安装Visual Studio服务包之后），需要重复执行此过程。

更新：

看起来OP并没有使用MFC，所以可能是两个不同的问题。我自己也经历了大小增加的情况，但不幸的是，由于我的项目静态链接到MFC，我无法确定是否是由MFC引起的。