Re: Compile speed: Pascal(Delphi) vs C++

Most of the reason is that Borland traditionally take great pains to
make their compilers fast. There are some aspects of the C++ and C
languages that make the languages difficult to compile quickly. Here
are a few common problems.


1) The compiler


Borlands compilers are optimized for speed, not to give good code. In
the quite recent past they were written in assembly language. Pascal
is marginally easier to parse than C, so the compiler has more scope
for speed. Both are easier to parse (and therefore potentially
faster) than C++.


As far as optimizations go, what is important is not how good the
compiler is, but how good it is at its highest setting. Set it to
almost no optimization for debugging and only use optimization when
you get near to the final release. So in principle there is no good
reason why a compiler shouldn't be fast and give good code on the
final build. In practice I haven't found one thats both very good and
very fast.


Some compilers have always been better than others.


2) Header files
As other posters have mentioned header files take time to compile. This
can cause problems in several situations:-


- You've written a program that includes one huge header file everywhere
when most of it isn't needed everywhere. This is completely brain dead
programming but not uncommon since header files grow in size over time.
    It happens quite a lot in C++ because many people who write it don't
understand it very well.


- You've written a program where one header file really is needed
everywhere. In that case, sorry but C'est la vie.


- Some idiot has written libraries that require huge header files. For
instance including the C++ iostreams header file on the computer I'm
sitting at produces a file 21000 lines long. This is mainly the fault
of the designers of the C++ standard, I'm tempted to say some very
impolite things about them, but I'll resist it for now.


If you have a compiler with caching pre-compiled headers these problems
will be reduced significantly.


3) Going through assembly langauge.


Some C compilers compile to assembly language and then invoke the
assembler, this causes some overhead.


4) Being unable to pipe between the parts of the compiler


The compiler should use pipes to communicate with the preprocessor and
the assembler, in some cases it won't so there will be some extra
overhead reading a writing files.


5) Misusing recursive make


Makefiles invoking other makefiles and doing things twice. A good
reason to avoid recursive make.

Return to the comp.compilers page.
Search the comp.compilers archives again.