optimization (was Re: C vs. FORTRAN (efficiency))

[Jeffrey Kegler]

Flint Pellett (flint%gistdev at uxc.cso.uiuc.edu) writes:
=> I haven't studied this myself, but my theory is that if you could
=> plot a graph of productivity vs time needed to compile, that curve
=> would be bell shaped for many people: toward the bottom where
=> compiles are instantaneous, productivity would be less because the
=> programmer would be charging ahead without ever stopping to think
=> about what they are doing, and would ending up wasting time doing
=> things that some pre-planning would have eliminated.

A lot of my compiles, and I suspect many other people's, are
recompiles of large systems where we are testing the result of
changing a single define.  The change and test require next to no
thought but the recompile involves tens of thousands of lines.  As
often as not, the change is to a configuration file which is included
by *.c, so make does not speed things up--just saves a lot of typing.
Face it, compile speed is A Good Thing for productivity.  If you get
me a compiler that will recompile GNU Emacs in 30 seconds, I may waste
some time at first, but I will learn to live with it, I promise you.
I'm looking forward to the problem, in fact.

The productivity versus runtime efficiency dilemma, of course, still
remains in full force.  An interesting wrinkle is when the things you
are compiling are productivity tools themselves--do you want an editor
that compiles 5% faster or runs 5% faster?
-- 

Jeffrey Kegler, Independent UNIX Consultant, Algorists, Inc.
jeffrey at algor2.ALGORISTS.COM or uunet!algor2!jeffrey
1762 Wainwright DR, Reston VA 22090