Delphi：如何组织源代码来增加编译器的性能？ [英] Delphi: How to organize source code to increase compiler performance?

问题描述

我正在一个大型的delphi 6项目上工作，有很多的依赖。编译整个项目需要几分钟的时间。几次更改后的重新编译有时会更长，以便更快地终止Delphi，清除所有的dcu文件并重新编译所有内容。

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

我已经尝试过以下操作：

• 明确地将dpr中的大多数单元都包含在内，而不是依赖搜索路径：没有改进任何东西。


• 使用命令行编译器dcc32：它是尝试看看编译器的工作（使用SysInternals中的ProcessExplorer）：显然它大部分时间运行着一个名为KibitzGetOverloads的函数。但是我不能对这些信息做任何事情...

编辑，到目前为止的答案总结： strong>

在我的情况下，效果最好的答案：

• 功能从 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）

解决方案

在中使用

• 冗余单位条款。见这个问题链接到 CnPack 。


• 不明确地将单位添加到项目文件中。


• 更改编译器设置，最显着的是包括TDD32信息。

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

I'm working on a large delphi 6 project with quite a lot of dependancies. It takes several minutes to compile the whole project. The recompilation after a few changes is sometimes much more longer so that it is quicker to terminate Delphi, erase all dcu files and recompile everything.

Does anyone know a way to identify, what makes the compiler slower and slower? Any tips how to organize the code to improve compiler performance?

I have already tried following things:

• Explicitly include most of the units in the dpr instead of relying on the search path: It didn't improve anything.
• Use the command line compiler dcc32: it isn't faster.
• Try to see what the compiler does (using ProcessExplorer from SysInternals): apparently it runs most of the time a function called 'KibitzGetOverloads'. But I can't do anything with this information...

EDIT, Summary of the answers until now:

The answer that worked best in my case:

• The function "Clean unused units references" from cnpack. It almost automatically cleaned more than 1000 references, making a "cold" compilation about twice faster. ("cold" compilation = erase all dcu files before compiling). It gets the reference list from the compiler. So if you have some {$IFDEF } check that all your configurations still compile.

The next thing I would like to try:

• Refactoring the unit references manually (eventually using an abstract class) but it is much more work, since I first need to identify where the problems are. Some tools that might help:
  • GExperts adds a project dependencies browser to the delphi IDE (but unfortunately it can not show the size of each branch)
  • Delphi Unit Dependency Viewer V1.0 do about the same thing but without Delphi. It can calculate some simple statistics (Which units is the most referenced, ...)
  • Icarus which is referenced on a link in one of the answer.

Things that didn't change anything in my case:

• Putting every files from my program and all components in one folder without subfolders.
• Defragmenting the disk (I tried with a ramdisk)
• Using a ramdisk for the code source and output folders.
• Turning off the live scanning antivirus
• Listing all the units in the dpr file instead of relying on the search path.
• Using the command line compiler dcc32 or ecc32.

Things that didn't apply to my case:

• Avoiding having dependencies on network shares.
• Using DelphiSpeedUp, because I already had it.
• Using a single folder for all dcu (I always do it)

Things that I didn't try:

• Upgrading to another Delphi version.
• Using dcc32speed.exe
• Using a solid-state drive (I didn't tried it, but I tried with a ramdisk where I put all the source code. But maybe I should have installed delphi on the ramdisk too)

解决方案

Some things that could slow down the compiler

• Redundant units in your uses clause. See this question for a link to CnPack.
• Not explicitly adding units to your project file. You've already seem to have covered that.
• Changed compiler settings, most notably include TDD32 info.

Try to get rid of unused units in your uses clause and see if it makes a difference.

这篇关于Delphi：如何组织源代码来增加编译器的性能？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！