Delphi大型VCL项目编译耗时优化咨询及问题排查

项目背景 #

• 150万行代码规模，在4GHz 12代Intel CPU上用Delphi 12.3编译耗时约20分钟（同规模其他项目仅需数秒至数分钟）
• 32位VCL项目，暂未迁移64位
• 包含5500个PAS单元：约半数为应用代码，其余为组件/库；其中2560个文件小于4k，4500个小于16k，5000个小于32k
• 部分单元implementation段的uses列表长达500个，interface段为5-20个
• 代码大量使用旧式object而非class，包含众多接口

问题1：合并单元能否提升编译速度？是否有自动工具？ #

• 合并单元确实能提速：Delphi编译器处理每个单元都有固定的初始化开销，比如解析单元结构、检查依赖、生成中间文件等。大量小型单元会把这些开销累积放大，合并逻辑相关的小型单元，能减少单元总数，降低重复的依赖解析操作，直接缩短编译时间。
• 自动工具现状：没有能全自动合并单元的工具——单元间的依赖关系太复杂，合并后很容易出现命名冲突、循环依赖等问题。可以用辅助工具梳理依赖：比如CNPACK的依赖分析功能，或者Delphi自带的依赖树查看器（通过Project > View Dependency Tree打开），先理清单元关联，再手动合并功能相近的小型单元。

问题2：旧式object和大量接口是否拖慢编译？ #

• 旧式object基本不影响：这种非类类型的对象，编译器解析逻辑比class更简单，处理速度更快，不会是编译慢的主要原因。
• 大量接口的影响有限：只有当接口存在复杂继承链、频繁的GUID引用，或者伴随大量冗余uses、复杂条件编译时，才会增加编译器的类型检查耗时，但通常不是核心瓶颈。

已验证的有效优化方案 #

用CNPACK清理单元的uses列表，手动修复清理后出现的语法错误，编译时间从原来的30分钟降到了5分钟。

• 核心原理：冗余的uses会让编译器反复解析不必要的单元，平白增加依赖检查和编译的工作量，清理后能大幅减少无效的单元解析操作。
• 局限性：清理结果只适配当前项目的条件编译指令，切换到其他配置（比如不同编译宏、平台）时，可能需要手动补全缺失的引用。

内容的提问来源于stack exchange，提问作者kgz