Re: Very long build times



Hi,

This is a known problem with the Delphi compiler.

I have been experiencing this for a while, and eventually got to the point
of shipping our entire code base to Borland for them to look at.

In our case our build times had extended out to 25minutes, but a relatively
simple reorganization of the code dropped the build time back to about 2.5
minutes (which we still thing is too slow!).

The problem is basically that the compiler processes units in a recursive
manner, and if a unit has not been compiled *completely* in one go, the next
time it is encountered, the compiler processes that unit again *from
scratch*!!!!!!!!!!!!

I have been told that borland are working on a new unit compiler engine that
should address this, but not idea of time frame.

This information is based on conversations with Borland a couple of months
ago.

In our case, we had a main class (lets call it TMain, in unit Main.pas...),
which holds everything else in our system. Main.pas has just about every
unit in the project in its interface uses clause. In turn, just about every
unit in the project has Main in its implementation uses clause.

We had been noticing our compile times slowing down as the project grew, but
it was gradual. When our build times got to around 7 minutes we suddenly
stopped and went hunting for the cause. Using our Version Control System, we
worked backwards, day by day looking for a checkin that caused a noticable
increase in build times. We eventually found a big slowdown when a unit had
been changed to use Main in its implementation section.

Our reorganization was to create a new class TMainAbstract, in
MainAbstract.pas, which was basically everything that used to be in TMain.

Main.pas then became:
------------
unit Main

interface

uses
MainAbstract;

type
TMain = class( TMainAbstract )
end;
implementation

end.
------------

For our project, this change has given us a 10x improvement in build times.

I hope this information is helpful to you, and I hope that Borland will have
this issue sorted out for the next version of Delphi (we're using Delphi 7,
and have found that the build times have only got worse with D2005 and
D2006).


Cheers,
Alistair Ward.




"Nikos Bakolas" <nospam_nikos_nospam@xxxxxxxxxxxxxxxxxxx> wrote in message
news:44591f88$1@xxxxxxxxxxxxxxxxxxxxxxxxx
Hi,
I work for a company which develops a medium sized application in Delphi
2006. At the early stages of development compilation was extremely quick,
usually taking less than a minute for a full build (100,000 lines of code)
on a 512MB Pentium 4 at 2.0GHz. However the last two years, we are
experiencing insufferably long build times. The build process takes more
than 17 minutes to compile 420,000 lines of code distributed among 340
units. This is on a high-end machine (1GB dual core AMD 4400+).
By observing the compiler progress dialog, I've noticed the following
things:
1. The first 10 seconds the compiler speeds through the first 100,000
lines of code.
2. During the next 15 minutes it slowly makes its way through the next
100,000 lines of code. In this stage, the field 'Current line' never
prints a value higher than 100, perhaps indicating that the compiler is
trying to resolve interface references.
3. After line 230,000 the build process speeds up and finishes building
in just under 30 seconds.
What I am interested in knowing is has anybody experienced anything
similar? What are your build times?
Thanks,
Nikos Bakolas


.



Relevant Pages

  • Alternative Future of Delphi?
    ... relevant compiler or interpreter... ... No more intricate code generation required for a particular platform ... on the Delphi compiler side. ...
    (borland.public.delphi.non-technical)
  • Re: Which Delphi Version To Buy
    ... Given the fact that Delphi compiler is quick and small, do you see feasible having a runtime compiler/parser enabling what you describe above? ... For example the basic data types processing in Delphi is sensibly superior to .NET's one exactly because is closer to the iron. ... Well, for parallel programming I, for one, certainly feel the need of a VM simply because the actual CPU architecture is far from the way in which humans deal with the reality which is parallel. ... The vast majority of the games you have to deal with /different/ characters doing /different/ actions in parallel, responding each one to the stimuli which comes from the environment. ...
    (borland.public.delphi.non-technical)
  • D7 revival? stirring the old pot + Delphi 64 suggestion
    ... The new compiler, but with the old IDE, the old help. ... You can check other areas of the site and poster stats, it's not that Delphi posters don't use .Net, it's just that they don't use Delphi for .Net work. ... As for the 64bit debugging, a CPU view debugger would be all that is really needed to get things started (this is for fastcode after all), no need for rich source-level debugging, inspectors, etc. early on. ... Validation could be two-ways: one in the fastcode challenge, another made via CodeGear private unit tests. ...
    (borland.public.delphi.non-technical)
  • Re: Compiler optimisation
    ... > Keep in mind that Delphi is one-pass compiler. ... > limits number of possible optimizations to ones that do not operate ...
    (borland.public.delphi.non-technical)
  • Re: Version after Version
    ... merely because Delphi has no 64-bit compiler? ... >> targeted instructions and increasing the size of the cache to 32,000 ... >> That has nothing to do with the number of address lines on the CPU ...
    (alt.comp.lang.borland-delphi)