我的公司十多年来一直在德尔福上运行一个大型项目。我们的代码库多年来一直在增长，目前代码数量约为 400 万行。编译速度正在成为一个问题。我们花了时间清除单元循环引用（编译缓慢的已知原因）并检查了设置的各个方面。已经到了我们无法通过我们所能控制的程度进一步实质性改进的地步。
目前，在运行 Windows XP SP3 和 Delphi 2006 的最先进的 4 核 PC 上，重新启动 Delphi 并进行完整构建，大约需要 40 秒。然后，如果我们立即在同一个 Delphi 会话中进行另一个完整构建，则将需要 1m 40s。再次进行完整的构建，情况会变得更糟。等等等等。
（我们很清楚Windows本身会缓存文件，这对编译速度影响很大。上面的数字是基于文件被缓存的情况。我们设置这样的场景是让Delphi编译一次项目，终止它，然后启动一个新的 Delphi 会话。因此，虽然 40 秒看起来并不慢，但这只是因为 Windows 缓存了文件。我们这样做是为了进行逐个比较。）
让我们困惑的是为什么编译速度会变差。 （我们过去观察到，如果项目有大量单元循环引用，速度会更慢。）如果我们终止 Delphi 并启动一个新会话，编译时间将回到 40 秒。我们观察到的更有趣的事情是，通过单击“取消”按钮中止编译，然后立即进行完整构建，我们可以实现相同的速度“改进”。编译时间也将恢复到 40 秒。
在我们看来，Delphi 自己的单元依赖缓存并不像从头开始构建它那么有效，而且随着时间的推移，它会变得越来越糟。而且“取消”按钮似乎也会以某种方式清除此缓存。我们的想法是，如果我们能够利用Delphi IDE子系统来进行这种清理，我们就可以始终将编译速度保持在峰值性能。但我们不知道怎么做。
有谁知道我们能做什么？
我们仍在使用 Delphi 2006，因为我们还没有找到将我们的大型项目移植到 Unicode 的可行方法。我在论坛上读到，最新的 Delphi XE 也出现了与单元循环引用类似的编译速度问题。有人知道 Delphi XE 是否解决了这个问题吗？
附注我们还意识到，将项目拆分为运行时包可以减少编译时间。但出于部署和管理原因，我们尽量避免使用运行时包。
如果您构建应用程序，可以使用以下一些技巧来加快该过程：
- 在构建之前删除所有 *.dcu (
del *.dcu /s);
- Run a 好的碎片整理程序 https://web.archive.org/web/20150923174633/http://www.mydefrag.com:80/在您相应的硬盘上；
- 将大部分源文件放在同一目录中，并尝试使 IDE 和项目库路径尽可能短，首先使用最常用的条目；
- Install 德尔福加速器 https://www.idefixpack.de/blog/ide-tools/delphispeedup/.
Delphi 2007 的编译速度应该比 Delphi 2006 更快。
Delphi 2009/2010/XE 可能会更慢：从用户实验来看，泛型和新 RTTI 的实现使编译过程更加复杂，并且发现实际实现更慢，例如与 Delphi 2007 相比。
Update:
您是否尝试启用项目ClearUnitCacheItem隐藏菜单项？
我已经通过 CnPack 启用了此条目，或者通过DDev扩展 https://www.idefixpack.de/blog/ide-tools/ddevextensions/（我不知道是哪一个做的，可能是后者）。这可用于清除内部单元缓存。
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
