Re: Speedy compilers

Joachim Durchholz <joachim.durchholz@munich.netsurf.de> writes:


> > [Given the relative speeds of Turbo C and Visual C++, I expect that
> > this lesson may no longer apply. -John]
>
> The lesson still applies, but there is no fast C++ compiler on Windows
> (not because C++ is slow but because these compilers all include
> megabytes of Windows header files by default). I think a compiler
> that uses precompilation in a sensible manner will blow the socks off
> all existing C++ compilers. ...


IBM's Visual Age C++ 4.0 compiler is supposed to solve this problem by
treating each function (rather than each 1000 lines) separately, and
then maintaining a dependency graph to tell it how to recompile when a
change is made. For example, if you have a function that creates a
stack object from class X, then it depends on the size of X. If you
change the size of X, then that function is recompiled. If you have
another function that creates a heap object from class X, then it
probably does not depend on the size of X. If you change the size of
X, the compiler would know that the function does not have to be
recompiled.


The header files are read in once and put into the dependency graph.
After that, unless they are not modified (either by editing the file
or by changing macros that they depend on), they do not have to be
re-analyzed. This is GREAT for those megabytes of Windows headers.


The demo of this system is impressive. The demonstrator made changes
to a Windows application, and the recompile took around 1 second. Of
course, changes that affect a lot of code will take longer (especially
if you change a function that is being inlined in many places), but
most changes I make are not to the header files, but rather to
implementation files, so I think most of the time I'd get speedy
compiles.


Unfortunately, it was 1996 when I saw the demo, and two years later,
it's still not released. (I suspect they were waiting for the C++
Standard.) I think it's now in beta.


- Amit


--
Amit J Patel, Computer Science Department, Stanford University

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