有谁知道一种方法来识别，什么使编译器越来越慢？任何提示如何组织代码来提高编译器性能？

我已经尝试以下事情：

>显式地包括dpr中的大多数单元，而不是依赖于搜索路径：它没有改善任何东西。
>使用命令行编译dcc32：它不快。
>尝试看看编译器做了什么(使用SysInternals的ProcessExplorer)：显然它运行大部分时间一个名为“KibitzGetOverloads”的函数。但我不能对这些信息做任何事情…

编辑，到目前为止的答案摘要：

在我的情况下最好的答案：

>功能“清除未使用的单元引用”从cnpack.它几乎自动清除超过1000个引用，使“冷”编译大约两倍快。 (“冷”编译=在编译之前擦除所有dcu文件)。它从编译器获取引用列表。所以如果你有一些{$ IFDEF}检查所有的配置仍然编译。

接下来我想尝试一下：

>手动重构单元引用(最终使用抽象类)
但它是更多的工作，因为我首先需要确定问题在哪里。一些工具可能有助于：

> GExperts将一个项目依赖浏览器添加到delphi IDE(但不幸的是它不能显示每个分支的大小)
> Delphi Unit Dependency Viewer V1.0做同样的事情，但没有德尔福。它可以计算一些简单的统计(哪些单位是最引用的，…)
> Icarus在a link中引用的一个答案。

在我的情况下没有改变任何事情：

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

不适用于我的案例的事情：

>避免依赖于网络共享。
>使用DelphiSpeedUp，因为我已经有了。
>为所有dcu使用单个文件夹(我总是这样做)

我没有尝试的事情：

>升级到另一个Delphi版本。
>使用dcc32speed.exe
>使用固态驱动器(我没有尝试过，但我试过一个ramdisk，我把所有的源代码，但也许我应该安装delphi的ramdisk)