相关疑难解决方法(0)

我正在开发一个具有相当多依赖性的大型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)