为什么Delphi的编译速度降低了开放时间，我该怎么办？ [英] Why does Delphi's compilation speed degrade the longer it's open, and what can I do about it?

问题描述

我的公司已经在德尔福运行了十多年的大型项目。我们的代码库多年来一直在增长，现在大约有400万行代码。编译速度正在成为一个问题。我们已经花费了时间去除单位循环引用（已知的缓慢编译原因），并检查了设置的各个方面。在某种程度上，我们无法通过我们可以控制的方式进一步改善它。

目前，在一个最先进的PC上，有4个内核运行Windows XP SP3和Delphi 2006，启动Delphi新鲜，做一个完整的构建，需要大约40秒。那么，如果我们立即在同一个Delphi会话中进行另一个完整的构建，则需要1个40分钟。再做一次全面的建设，会变得更糟。所以，等等。

（我们很清楚Windows本身缓存文件，这对编译速度有很大的影响，上面的数据是基于文件缓存，我们设置这样的场景，让Delphi编译一次项目，终止它，然后启动一个新的Delphi会话，所以40秒看不到缓慢，这只是因为文件被Windows缓存我们这样做是为了有一个苹果到苹果的比较。）

令我们困惑的是为什么编译速度变得更糟。 （我们在过去观察到，如果项目有很多单位循环引用，则减速更糟）。如果我们终止Delphi并开始一个新的会话，编译时间将恢复到40秒。我们观察到的一个更有趣的事情是，我们可以通过点击取消按钮来中止编译，然后立即完成全面的构建，从而实现相同的速度改进。编译时间也会恢复到40秒。

我们看来，Delphi自己的单位依赖缓存并不像从头构建一样高效，而且越来越糟时间。而且，取消按钮也会以某种方式清除此缓存。我们正在想的是，如果我们可以利用执行此清除功能的Delphi IDE子系统，我们可以始终保持编译速度达到最佳性能。但是我们不知道如何。

有谁知道我们能做什么？

我们还在使用Delphi 2006，因为我们还没有找到一种将我们的大型项目移植到Unicode的可行方法。我在论坛上阅读了最新的Delphi XE与单元循环引用相似的编译速度问题。任何人知道Delphi XE是否解决了这个问题？

p.s。我们也意识到将项目拆分为运行时包可以减少编译时间。但是，为了部署和管理的原因，我们尽量避免使用运行时包。

解决方案

如果你构建你的应用程序，这里有一些技巧来加快这个过程：

• 在构建之前擦除所有* .dcu（ del * .dcu / s ）;


• 在相应的硬盘驱动器上运行（我不知道哪一个做这个，可能是以后）。这可以用于清除内部单元缓存。
  
  

  My company has been running a large project on Delphi for more than a decade. Our codebase has been growing over the years and now stands at around 4 million lines of code. Compilation speed is becoming an issue. We've spent time weeding out unit circular referencing (a known cause of slow compilation) and examined every aspect of the setup. It gets to a point we can't improve it any further materially with what we can control.

  At the moment, on a state of the art PC with 4 cores running Windows XP SP3 and Delphi 2006, start Delphi fresh and do a full build, it takes ~40 secs. Then, if we do another full build in the same Delphi session immediately, it will take 1m 40s. Do another full build again, it will get worse. So on and so forth.

  (We are well aware Windows itself caches files and this has a big impact on the compilation speed. The above figures are based on that the files are cached. We set up such scenario by getting Delphi to compile the project once, terminating it and then starting a new Delphi session. So while 40 secs doesn't see to be slow, it's only because the files are cached by Windows. And we do this in order to have an apple-to-apple comparison.)

  What puzzles us is why the compilation speed gets worse. (We have observed in the past the slow down was worse if the project had a lot of unit circular referencing.) If we terminate Delphi and start a new session, the compilation time will get back to 40 secs. An even more interesting thing we've observed is, we can achieve the same speed "improvement" by clicking the "Cancel" button to abort the compilation and then do the full build right away. Compilation time will get back to 40secs too.

  It appears to us Delphi's own cache of unit dependency isn't as efficient as building it from scratch and it is getting worse over time. And it also appears the Cancel button somehow clears this cache. What we are thinking is, if we can tap into the Delphi IDE subsystem that does this clearing, we can always maintain the compilation speed at its peak performance. But we don't know how.

  Does anyone know what we can do?

  We are still using Delphi 2006 as we haven't yet found a feasible way to port our large project to Unicode. I read on forums that the latest Delphi XE exhibits similar compilation speed issue with unit circular referencing. Anyone knows if Delphi XE has addressed the problem?

  p.s. We are also aware that splitting the project into runtime packages can reduce compilation time. But for deployment and administrative reasons, we try to avoid using runtime packages.

  解决方案

  If you build your application, here are some tricks to speed up the process:

  • Erase all *.dcu before the build (del *.dcu /s);
  • Run a good defragmenter on your corresponding hard drive;
  • Put most of your source files in the same directory, and try to leave the IDE and Project library paths as short as possible, with the most used entries at first;
  • Install DelphiSpeedUp.

  Delphi 2007 should compile faster than Delphi 2006.

  Delphi 2009/2010/XE would probably be slower: from user experiment, the implementation of generics and new RTTI made the compilation process more complex, and the actual implementation was found out to be slower e.g. than with Delphi 2007.

  Update:

  Did you try enabling the ProjectClearUnitCacheItem hidden menu entry?

  I've this entry enabled either by the CnPack, either by DDevExtension (I don't know which one do this, probably the later). This could be used to clear the internal unit cache.

  这篇关于为什么Delphi的编译速度降低了开放时间，我该怎么办？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！