为什么Delphi的编译速度会随着打开时间的延长而降低,我该怎么办呢？

Question

十多年来,我的公司一直在Delphi上运行一个大型项目.我们的代码库多年来一直在增长,现在大约有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是否解决了这个问题？

ps我们也知道将项目拆分为运行时包可以减少编译时间.但出于部署和管理原因,我们尽量避免使用运行时包.

Answer 1

如果你构建你的应用程序,这里有一些技巧来加快这个过程:

• 在build(del *.dcu /s)之前擦除所有*.dcu ;
• 在相应的硬盘上运行一个好的碎片整理程序 ;
• 将大多数源文件放在同一目录中,并尝试尽可能缩短IDE和项目库路径,最初使用最多的条目;
• 安装DelphiSpeedUp.

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

Delphi 2009/2010/XE可能会更慢:从用户实验,泛型的实现和新的RTTI使编译过程变得更加复杂,并且发现实际实现比使用Delphi 2007更慢.

更新:

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

我通过CnPack启用此条目,或者通过DDevExtension启用(我不知道哪一个执行此操作,可能是后者).这可用于清除内部单元缓存.

Answer 2

逐渐的性能下降可能是由于某种内存泄漏或编译器中的其他错误.天知道D2005和D2006已经足够了!如果您无法升级到支持Unicode的Delphi版本,那么您应该至少更新到D2007(我相信仍然可以从Embarcadero获得)以获得更好的稳定性.

另外,正如罗伯特·弗兰克在评论中提到的,请查看Andreas Hausladen的工具.就在几天前,他发布了一个补丁,可以提高编译速度.不幸的是,这个特定功能显然仅适用于D2009及更高版本,但他的许多修复程序有助于加快各种速度,包括编译器.

Answer 3

从Andreas Hausladen尝试DelphiSpeedUp非常值得,但这只会帮助IDE性能而不是我理解的编译.

没有人建议的另一个想法是使用高规格固态磁盘.

我建议使用具有大量RAM的64位Windows 7以获得最佳文件缓存性能.

感谢您的项目不是用C++编写的!