十多年来,我的公司一直在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我们也知道将项目拆分为运行时包可以减少编译时间.但出于部署和管理原因,我们尽量避免使用运行时包.
在我的一些非常大的项目中,这应该会减少可执行文件的大小.我相信还会有其他好处.
编辑:是否有一个实用程序可以扫描项目并自动删除多余的项目？我确实有100个项目,"自动删除"将是一等奖,但如果我必须,我会在识别实用程序的帮助下采用手动方式.
我的项目有大约400个单元,在重新启动后编译需要20-40秒,然后比后续重新编译需要1-5秒,到目前为止一切都很好.
工作超过3-6小时后,编译需要1-3分钟进行后续重新编译,这迫使我每次都重新启动.
D7的某个地方有泄漏吗？这是Windows XP的问题吗？它变得非常令人沮丧......
有谁遇到过这个问题？
Edit1 DelphiSpeedup似乎没有改善问题,它仍然发生....