Delphi:如何组织源代码以提高编译器性能?

Nam*_*ame 32 delphi compiler-construction optimization

我正在开发一个具有相当多依赖性的大型delphi 6项目.编译整个项目需要几分钟的时间.经过一些更改后重新编译有时会更长,以便更快地终止Delphi,擦除所有dcu文件并重新编译所有内容.

有没有人知道识别的方法,是什么让编译器变慢和变慢?有关如何组织代码以提高编译器性能的任何提示?

我已经尝试过以下事项:

  • 显式地包含dpr中的大多数单元而不是依赖于搜索路径:它没有改进任何东西.
  • 使用命令行编译器dcc32:它不是更快.
  • 试着看看编译器做了什么(使用来自SysInternals的ProcessExplorer):显然它大部分时间运行一个名为'KibitzGetOverloads'的函数.但我对这些信息无能为力......

编辑,答案总结到现在为止:

在我的案例中最有效的答案:

  • cnpack中的 "清理未使用的单元引用" 功能.它几乎自动清理了超过1000个引用,使"冷"编译速度快了两倍.("冷"编译=在编译之前擦除所有dcu文件).它从编译器获取引用列表.因此,如果您有一些{$ IFDEF}检查所有配置是否仍然编译.

接下来我想尝试一下:

  • 手动重构单元引用(最终使用抽象类),但它需要更多工作,因为我首先需要确定问题所在.一些可能有用的工具:
    • GExperts向delphi IDE添加了一个项目依赖项浏览器(但不幸的是它无法显示每个分支的大小)
    • Delphi Unit Dependency Viewer V1.0做同样的事情,但没有Delphi.它可以计算一些简单的统计数据(哪些单位被引用最多,......)
    • 在其中一个答案的链接上引用的Icarus.

在我的案例中没有改变任何事情的事情:

  • 将我的程序和所有组件中的每个文件放在一个没有子文件夹的文件夹中.
  • 对磁盘进行碎片整理(我尝试使用ramdisk)
  • 使用ramdisk作为代码源和输出文件夹.
  • 关闭实时扫描防病毒软件
  • 列出dpr文件中的所有单元,而不是依赖于搜索路径.
  • 使用命令行编译器dcc32或ecc32.

不适用于我案件的事情:

  • 避免依赖网络共享.
  • 使用DelphiSpeedUp,因为我已经拥有它.
  • 为所有dcu使用单个文件夹(我总是这样做)

我没试过的事情:

  • 升级到另一个Delphi版本.
  • 使用dcc32speed.exe
  • 使用固态驱动器(我没有尝试过,但我尝试使用ramdisk放置所有源代码.但也许我应该在ramdisk上安装delphi)

Lie*_*ers 11

一些可能会降低编译器速度的事情

  • 您的uses子句中的冗余单元.请参阅此问题以获取指向的链接CnPack.
  • 未明确将单位添加到项目文件中.你似乎已经涵盖了这一点.
  • 更改了编译器设置,最值得注意的是include TDD32 info.

尝试摆脱uses子句中未使用的单位,看看它是否有所作为.


小智 9

使用Delphi 7和2009,上周我通过了近2分钟的编译和另外45秒的命中f9并将我的应用程序的主要形式编译并运行了20秒.这件事让我疯狂了大约6个月,我尝试的任何东西似乎都没有用.使用来自SysInternals的filemon,我意识到编译器所需的每个单元(主要是组件)都在搜索路径中的每个文件夹中搜索,是的,这会生成很多FileOpen,FileExists和FileNotFound等.我做的是,把每个DCU,DFM,RES等来自组件全部在一个文件夹中,并且在搜索路径中只有这个文件夹,以及项目所需的其他几个文件夹; 结果太棒了.修复之前的其他问题是调试.每次F7需要almos 40秒,在调试时按F8键,这也已修复.希望这些信息可以帮到你.委内瑞拉Isla de Margarita的问候.请原谅我的英文,如果有任何错误;)


Bin*_*ier 8

检查搜索路径中是否存在本地计算机上没有的路径.

即,不要链接到网络共享上的二进制文件,并检查搜索路径是否未检查任何网络共享.


Lar*_*ens 5

您可以尝试DelphiSpeedUp,看看它是否有所作为.它不会加速命令行编译,但它声称有一些IDE编译的加速.