performance - 为什么Delphi打开时间越长编译速度就越慢，我该怎么办？

Question

我的公司十多年来一直在 Delphi 上运行一个大型项目。我们的代码库多年来一直在增长，目前代码数量约为 400 万行。编译速度正在成为一个问题。我们花了时间清除单元循环引用(编译缓慢的已知原因)并检查了设置的各个方面。已经到了我们无法通过我们所能控制的程度进一步实质性改进的地步。

目前，在运行 Windows XP SP3 和 Delphi 2006 的最先进的 4 核 PC 上，重新启动 Delphi 并进行完整构建，大约需要 40 秒。然后，如果我们立即在同一个 Delphi session 中进行另一个完整构建，则将需要 1m 40s。再次进行完整的构建，情况会变得更糟。依此类推。

(我们很清楚Windows本身会缓存文件，这对编译速度影响很大。上面的数字是基于文件被缓存的情况下的。我们设置这样的场景是让Delphi编译一次项目，终止然后启动一个新的 Delphi session 。因此，虽然 40 秒看起来并不慢，但这只是因为文件由 Windows 缓存。我们这样做是为了进行逐个比较。)

让我们不解的是为什么编译速度会变差。 (我们过去观察到，如果项目有大量单元循环引用，速度会更慢。)如果我们终止 Delphi 并启动一个新 session ，编译时间将回到 40 秒。我们观察到的更有趣的事情是，通过单击“取消”按钮中止编译，然后立即进行完整构建，我们可以实现相同的速度“改进”。编译时间也将恢复到 40 秒。

在我们看来，Delphi 自己的单元依赖缓存并不像从头开始构建它那么有效，而且随着时间的推移，情况会变得越来越糟。而且“取消”按钮似乎也以某种方式清除了该缓存。我们的想法是，如果我们能够利用Delphi IDE子系统来进行这种清理，我们就可以始终将编译速度保持在峰值性能。但我们不知道如何做到。

有人知道我们能做什么吗？

我们仍在使用 Delphi 2006，因为我们尚未找到将大型项目移植到 Unicode 的可行方法。我在论坛上读到，最新的 Delphi XE 也出现了与单元循环引用类似的编译速度问题。有人知道 Delphi XE 是否解决了这个问题吗？

附:我们还意识到，将项目拆分为运行时包可以减少编译时间。但出于部署和管理原因，我们尽量避免使用运行时包。

Answer 1

如果您构建应用程序，可以使用以下一些加快进程的技巧:

• 在构建之前删除所有 *.dcu (del *.dcu/s)；
• 运行 good defragmenter在相应的硬盘驱动器上；
• 将大部分源文件放在同一目录中，并尝试使 IDE 和项目库路径尽可能短，最常用的条目放在最前面；
• 安装DelphiSpeedUp .

Delphi 2007 的编译速度应该比 Delphi 2006 更快。

Delphi 2009/2010/XE 可能会更慢:从用户实验来看，泛型和新 RTTI 的实现使编译过程变得更加复杂，并且发现实际实现更慢，例如与 Delphi 2007 相比。

更新:

您是否尝试启用 ProjectClearUnitCacheItem 隐藏菜单项？

我已通过 CnPack 或 DDevExtension 启用了此条目(我不知道是哪一个做的，可能是后者)。这可用于清除内部单元缓存。