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

Steve Summit scs at adam.pika.mit.edu
Sun Aug 20 14:51:41 AEST 1989


In article <484 at gistdev.UUCP> flint at gistdev.UUCP (Flint Pellett) writes:
>...the simple arithmetic of saying that if it
>takes 10% off the time to do the compiles that there will be a result of
>10% higher productivity doesn't follow.  The problem is that any system is
>no faster than the slowest part, and eventually the slowest part ends up
>being the human part: a certain amount of time is required for a person to
>think and plan...

Just so.  The other thing that bugs me about requests for, or
claims of, faster compilers is that any compiler you have to wait
for will seem too slow.  Except when I'm tracking down exactly
one bug, I try to put all of my compiles in the background, and
work on another module in the meantime.  Under MS-DOS, I'd gladly
take a compiler two times *slower* if I could just put it in the
background.  (I'm not sure why I've put up with a job involving
DOS for as long as I have.)

                                            Steve Summit
                                            scs at adam.pika.mit.edu



More information about the Comp.lang.c mailing list