我有一个在 VS2008 下编译的相当大的 C++ 程序（~11mb exe），并且有兴趣了解整个程序优化是否会显着影响其性能。然而，打开整个程序优化和链接时代码生成会导致链接失败，如下所示；
1>c:\cpp\Win32\Atlas\tin\TINDoc.Cpp : fatal error C1083: Cannot open compiler intermediate file: '.\releaseopt\TINDoc.obj': Not enough space
1>LINK : fatal error LNK1257: code generation failed
查看任务管理器，我可以看到链接器使用越来越多的内存，直到耗尽并崩溃。编译器在 XP 32 位上运行，具有 2GB 内存和 2GB 页面文件。 WPO 是否仅限于较小的应用程序和/或较大的环境，或者是否有任何方法可以让链接器在内存使用方面更加节省。
注：已经关闭了预编译头，这导致编译在链接之前失败，并关闭了调试信息的输出以及任何可能占用额外资源的其他内容。 C1083 的帮助建议缺少头文件或文件句柄不足，而不是缺少空间。
Edit:在VS2010下可以运行，尽管没有预编译头，但性能提升并不那么显着。我将保留此选项，直到我转向具有更强大版本的 VS2010 的更强大的 64 位平台。
VC2008是一头脆弱的野兽。优化器在某些情况下不起作用，看起来您可能会遇到这样的情况。
“不工作”的示例包括
- 去优化的代码（慢！）
- 编译器或（更频繁地）链接器崩溃
- 模糊的编译/链接错误消息
- 错误的代码执行（这种情况很少见，但并非未知）。
事实上，如果你看看现代优化者使用的一些技巧，你会发现它如此频繁地发挥作用是非常令人惊讶的。其复杂程度相当惊人。
具体解决 Shane 的问题，一些可能会导致您的错误的事情：
在 DOS 和早期的 Windows 版本中，文件句柄耗尽曾经是一个大问题。在现代 Windows 版本中你几乎看不到它。我什至不确定文件句柄是否仍然存在限制。
编译器错误可能会导致无限循环，这意味着再多的资源也不够。
递归包含文件也可能导致类似的情况。您的所有包含文件是否都有“#pragma once" or "#if !defined(FOO_INCLUDED)"?
您是否有可能在项目中两次包含 TINDoc.obj 文件？ 2008 编译器是积极的多线程，并且尝试访问文件的两个线程之间可能存在争用。实际上，即使您没有两次包含该文件，这也可能通过编译器错误发生。
如果程序真的is如果太大，请考虑将其分解为一个或多个 DLL，然后逐一构建，或者将有争议的源文件拆分为多个文件，以便分多个阶段进行编译。
不要这么认为，因为它说“空间不足”，这一定是原因。某些程序（包括某些编译器）会猜测错误的原因，而不是进行检查。
您可以使用任务管理器或 perfmon 监视内存、句柄等的使用情况，或者（我的偏好）流程浏览器 http://technet.microsoft.com/en-us/sysinternals/bb896653
我已经将其第一部分作为评论发布（见上文），但我按照 Ben (http://stackoverflow.com/users/587803/ben) 的建议将其作为答案 - 并对其进行了一些扩展。
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
