Xref: utzoo comp.lang.c:27088 comp.lang.misc:4553
Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!snorkelwacker!bloom-beacon!scs
From: scs@athena.mit.edu (Steve Summit)
Newsgroups: comp.lang.c,comp.lang.misc
Subject: Re: A note for those not consumed by efficiency worries (was: function calls)
Message-ID: <1990Mar21.061420.9862@athena.mit.edu>
Date: 21 Mar 90 06:14:20 GMT
References: <1990Mar17.190858.13930@athena.mit.edu> <14278@lambda.UUCP>
Sender: news@athena.mit.edu (News system)
Reply-To: scs@adam.mit.edu (Steve Summit)
Organization: Lack Thereof
Lines: 53

In article <14278@lambda.UUCP> jlg@lambda.UUCP (Jim Giles) writes:
>From article <1990Mar17.190858.13930@athena.mit.edu>, by scs@athena.mit.edu (Steve Summit):
>> It is unfortunate that perpetual concerns about microoptimization
>> tend to suggest that function call overhead is unacceptable and
>> should be avoided.
>
>I quite agree.  No one in this thread of discussion has suggested otherwise,
>certainly not me.  In fact, I have argued this very point on this newsgroup
>in the recent past...

I hope it didn't sound like I had singled you out for criticism.
(I should have said "seem to suggest.")  I haven't been keeping
up with this list of late, and so wouldn't have seen your earlier
comments.

>> (Remember, too, that function calls on any machine are by no
>> means "slow."  This discussion is splitting hairs between
>> "extremely fast" and "ridiculously fast..."
>
>This is simply not true.  Procedure calls are the slowest 'single operations'
>that high-level languages provide...
>If you claim that procedure calls are fast, let's see your benchmark.

I knew I was gonna get reamed on this one, and you're all going
to groan when you hear the justification I had in mind all along.
My benchmark is from a PDP 11/23, using Ritchie's compiler.  I
measure approximately 60 microseconds per subroutine call, plus
about 4 microseconds per argument pushed.  (This in spite of the
fact that small run-time subroutines are called in the midst of
procedure call and return to build up and tear down the stack
frame.)

60 microseconds may not seem "fast" when compared with more
modern processors, but I assure you that, in real terms, it is a
tiny period of time indeed.  You and I can't do much of anything
in 60 microseconds.  One of the facts inevitably overlooked in
efficiency discussions (even more often than the fact that it
shouldn't be worried about too early) is the fact that computers
are intrinsically very, very fast.  It's their job.  And for most
of the code in most programs, they are quite fast enough.

I know y'all know this, as in fact I know that there are times
when efficiency does matter.  I just feel compelled to scramble
up on this soapbox from time to time to make sure that the other
side gets heard.  The industry is not plagued by software that is
too slow.  It is plagued by software that is behind schedule,
full of bugs, and impossible to maintain.  Too many programmers
seize upon the flimsiest excuses to abandon clean, simple coding
in favor of some purportedly more efficient implementation, which
is why I get defensive whenever efficiency is discussed.

                                            Steve Summit
                                            scs@adam.mit.edu