为什么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会话中立即做另一个完全构建，它将需要1m 40s。做另一个完整的构建，它会变得更糟。

（我们很清楚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屋！