为什么Delphi的编译速度会降低开放时间，我能做些什么呢？
我的公司在delphi运行了一个大型项目十多年。 我们的代码库多年来一直在增长，现在已经达到了400万行代码。 编译速度正在成为一个问题。 我们花了时间去除单位循环引用（一个已知的编译速度慢的原因），并检查了设置的每个方面。 这一点我们无法用我们能够控制的东西进一步实现。
目前，在一台运行Windows XP SP3和Delphi 2006的4核处理器上，启动Delphi并重新编译，需要40秒。 那么，如果我们立即在同一个delphi会议上再做一个完整的构build，则需要1个40秒。 再次做一个完整的构build，它会变得更糟。 等等等等。
（我们很清楚Windows本身caching文件，这对编译速度有很大的影响，上面的数据是基于文件被caching的，我们通过Delphi编译这个项目来设置这个场景，终止它，然后开始一个新的Delphi会话，所以40秒看起来并不慢，只是因为这些文件被Windowscaching，而我们这样做是为了进行苹果对苹果的比较。
令我们困惑的是为什么编译速度变得更糟。 （过去我们观察到，如果这个项目有很多单位的循环引用，那么速度就会变慢。）如果我们终止Delphi并开始一个新的会话，编译时间将回到40秒。 更有意思的是，我们可以通过点击“取消”button中止编译，然后立即完成全部构build，从而达到相同的速度“改善”。 编译时间也会回到40secs。
在我们看来，delphi自己的单元依赖caching效率不如从头开始构build，而且随着时间的推移而变得越来越糟糕。 它也出现取消button不知何故清除此caching。 我们的想法是，如果我们可以利用Delphi IDE子系统来完成这个清理工作，我们总是可以保持编译速度达到最高性能。 但我们不知道如何。
有谁知道我们可以做什么？
我们还在使用Delphi 2006，因为我们还没有find一个将我们的大型项目移植到Unicode的可行方法。 我在论坛上看到，最新的Delphi XE在单元循环引用方面performance出类似的编译速度问题。 任何人都知道delphiXE是否解决了这个问题？
ps我们也知道把项目拆分成运行时包可以减less编译时间。 但是出于部署和pipe理的原因，我们尽量避免使用运行时软件包。
如果你build立你的应用程序，这里有一些技巧来加快这个过程：
- 删除构build之前的所有* .dcu（
del *.dcu /s）; - 在相应的硬盘上运行一个好的碎片整理程序 ;
- 将大部分源文件放在同一个目录中，尽量使IDE和Project库path尽可能短，首先使用最常用的条目;
- 安装DelphiSpeedUp 。
Delphi 2007应该比Delphi 2006编译得更快。
Delphi 2009/2010 / XE可能会比较慢：从用户实验来看，generics和新RTTI的实现使得编译过程变得更加复杂，实际的实现比Delphi 2007更慢。
更新：
你尝试启用ProjectClearUnitCacheItem隐藏的菜单项吗？
我已经通过CnPack启用了这个条目，要么由DDevExtension （我不知道哪一个这样做，可能是后者）。 这可以用来清除内部单元caching。
性能逐渐下降可能是由于某种内存泄漏或编译器中的其他错误引起的。 天知道D2005和D2006已经足够了！ 如果你不能升级到支持Unicode的Delphi版本，至less应该更新到D2007（我相信它仍然可以从Embarcadero获得），以获得更好的稳定性。
另外，正如罗伯特·弗兰克在评论中提到的，请查看Andreas Hausladen的工具。 就在几天前，他发布了一个可以提高编译速度的补丁。 不幸的是，这个特定的function显然只适用于D2009以及更高版本，但是他的很多修复function都可以帮助加速各种function，包括编译器。
从Andreas Hausladen尝试DelphiSpeedUp非常值得，但是这只会帮助IDE的性能而不是编译，因为我理解它。
另一个没有人提出的想法是使用高规格的固态硬盘。
我build议使用具有大量内存的64位Windows 7以获得最佳的文件caching性能。
感谢您的项目不是用C ++编写的！
考虑使用运行时软件包进行内部构build，然后在向QA部门发送代码或分发应用程序时构build单一的可执行文件。
这需要额外的维护，但构build时间的急剧增加值得IMO。
我们有一个2.4 MLOC项目，大约有40-50个小的支持应用程序。 当针对一组运行时软件包进行编译时，该项目的构build速度约为500K，构build速度提高了6倍（15秒比90秒）。 很多较小的应用程序都是在一秒或更短的时间内编译的，因为这么多的打包代码是共享的。
您需要确保testing单片可执行文件，而不是打包的可执行文件。 但是，如果遵循良好的编码习惯，通常你不应该看到太多的行为差异。
这个问题有更多的build议，以获得更好的编译速度。 避免循环引用和检测未使用的单位（使用CnWizards）会产生更大的影响。
你有没有尝试使用脚本命令行编译代码？
从命令行重新编译，使进程站在40秒？
从cmd“dcc32.exe”运行来查看使用情况。
更新：我现在不能检查它，但是你应该尝试从命令行编译，看看你是否尝试从ide运行，IDE不应该重新编译，并让你运行debugging。
