Re: Speedy compilers

Joachim Durchholz <>
24 Nov 1998 22:19:57 -0500

          From comp.compilers

Related articles
Speedy compilers (Kirk Abbott) (1998-11-06)
Re: Speedy compilers (Janusz Szpilewski) (1998-11-15)
Re: Speedy compilers (1998-11-19)
Re: Speedy compilers (Jack W. Crenshaw) (1998-11-19)
Re: Speedy compilers (Toon Moene) (1998-11-21)
Re: Speedy compilers (Joachim Durchholz) (1998-11-24)
Re: Speedy compilers (Andrew Fry) (1998-11-24)
Re: Speedy compilers (Robert Bernecky) (1998-11-24)
Re: Speedy compilers (1998-11-30)
Re: Speedy compilers (Janusz Szpilewski) (1998-11-30)
Re: Speedy compilers (Amit Patel) (1998-12-10)
Re: Speedy compilers (1998-12-13)
[11 later articles]
| List of all articles for this month |

From: Joachim Durchholz <>
Newsgroups: comp.compilers
Date: 24 Nov 1998 22:19:57 -0500
Organization: Compilers Central
References: 98-11-047 98-11-086 98-11-089
Keywords: performance

> > So compile speed is a very important factor and compiler designers
> > should treat it seriously...

> One lesson I learned from too many years in graduate school and many
> more in industry is it is commercially infeasible to try to sell a
> slow compiler.

Amen to that. Most (nearly all) of my compiler exposure has been at
the using end, and a slow compiler so seriously disrupts work that I'd
switch to a faster compiler at the drop of a hat. What I'd like to
see, though, is a compiler with a "fast" mode and a "production"
mode. Fast mode is optimized towards creating something executable as
fast as possible to keep the development cycle at a high
rate. Production mode does all the optimization and whatever makes
compilation slow. (An *excellent* system would run the compiler in
production mode during idle time.) To make that work, the compiler
would have to make 100% sure that fast mode and production mode will
generate object code with the same semantics, which is where my vision
probably gets unrealistic... but I'd *really* like to have something
like this.

> A study in human psychology might decide when a compiler is 'fast
> enough'; I suspect users would claim a compiler is 'fast enough' if
> the response time is close to instantaneous, regardless of the
> program being compiled.

Not really. The compilation time should be proportional to the editing
time. Maybe modulo a "seriousness" factor: If I change something high
up in the hierarchy, I can expect that more need be recompiled (but I
think that compiler users will accept even this only grudgingly).

> [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. For example, by keeping a precompiled file
for every source file instead of a single precompiled header that has
to fit all sources. Even better would be a segmented precompiled file
that could restart compilation in increments of, say, 1000 lines
(i.e. dump out the compiler state every 1000 LOC, and for each new
compilation, look how far the source is unchanged and restart
compilation at that point).


Post a followup to this message

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