|Speedy compilers email@example.com (Kirk Abbott) (1998-11-06)|
|Re: Speedy compilers firstname.lastname@example.org (Janusz Szpilewski) (1998-11-15)|
|Re: Speedy compilers email@example.com (1998-11-19)|
|Re: Speedy compilers firstname.lastname@example.org (Jack W. Crenshaw) (1998-11-19)|
|Re: Speedy compilers email@example.com (Toon Moene) (1998-11-21)|
|Re: Speedy compilers firstname.lastname@example.org (Joachim Durchholz) (1998-11-24)|
|Re: Speedy compilers email@example.com (Andrew Fry) (1998-11-24)|
|Re: Speedy compilers firstname.lastname@example.org (Robert Bernecky) (1998-11-24)|
|Re: Speedy compilers email@example.com (1998-11-30)|
|Re: Speedy compilers firstname.lastname@example.org (Janusz Szpilewski) (1998-11-30)|
|Re: Speedy compilers email@example.com (Amit Patel) (1998-12-10)|
|Re: Speedy compilers firstname.lastname@example.org (1998-12-13)|
|[11 later articles]|
|From:||Joachim Durchholz <email@example.com>|
|Date:||24 Nov 1998 22:19:57 -0500|
|References:||98-11-047 98-11-086 98-11-089|
> > 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
> 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).
Return to the
Search the comp.compilers archives again.