Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!csd4.csd.uwm.edu!bionet!agate!ucbvax!bloom-beacon!adam.pika.mit.edu!scs
From: scs@adam.pika.mit.edu (Steve Summit)
Newsgroups: comp.lang.c
Subject: Re: optimization (was Re: C vs. FORTRAN (efficiency))
Message-ID: <13654@bloom-beacon.MIT.EDU>
Date: 20 Aug 89 04:51:41 GMT
References: <3288@ohstpy.mps.ohio-state.edu> <225800204@uxe.cso.uiuc.edu> <14523@bfmny0.UUCP> <1613@mcgill-vision.UUCP> <14556@bfmny0.UUCP> <484@gistdev.UUCP>
Sender: daemon@bloom-beacon.MIT.EDU
Reply-To: scs@adam.pika.mit.edu (Steve Summit)
Lines: 19

In article <484@gistdev.UUCP> flint@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@adam.pika.mit.edu