Xref: utzoo comp.lang.c:27067 comp.lang.misc:4532
Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!mstan!amull
From: amull@Morgan.COM (Andrew P. Mullhaupt)
Newsgroups: comp.lang.c,comp.lang.misc
Subject: Re: A note for those not consumed by efficiency worries (was: function calls)
Summary: Two ways to worry about efficiency here.
Message-ID: <790@s7.Morgan.COM>
Date: 20 Mar 90 07:09:48 GMT
References: <1990Mar17.190858.13930@athena.mit.edu> <14278@lambda.UUCP>
Organization: Morgan Stanley & Co. NY, NY
Lines: 45


The discussion so far about C's excess function call overhead hasn't
really differentiated between the two sides of the efficiency concern.
There are two distinct points to be made, and the come from different
points of view.

Most programmers might say that they are not overly concerned with the
efficiency of a single function call. In fact, they would be happier
if they could be completely unconcerned with the issue. These are the
people (myself totally included) who want to use functions to properly
structure their code. 

A small minority, (perhaps they have to write high pressure versions
of algorithms which are rich in complex recursive data structures,
or they implement 2-D random choice methods, or Multigrid methods,
or some other important example of a function call overhead rich
application), might have to admit that they have been forced to
write their source code around reducing function call overhead.

The distance between these two points of view might be shorter than
it seems at first. Both groups are concerned with function call
overhead, but the first group are adequately served by their compilers,
and the second group have to strap on their big boots and do it on
their own. The first group are _vicariously_ concerned with function
call overhead. We want the compiler to apply every exigency and
subterfuge to arrive at the last word in object code, no matter how
much readability liberty we have taken in the source. (So we have
no need to worry about this issue when coding.)

C compilers have to treat this issue seriously, since C often uses
a slower calling convention than Pascal or FORTRAN, in order that
C can support functions with a nonconstant number (and/or type) of
arguments. Many C compilers are specially equipped to generate good
code for function calls despite this possible handicap, and it is
entirely to their credit. But this is no reason to ignore the point.
The way that I find myself normally thinking about function call
overhead is in case I wonder if I've somehow put my compiler off the
scent unnecessarily, or if I have to consider this possibility while
troubleshooting something else that isn't performing up to scratch.
It is at these times when members of the first group of programmers
("let the compiler take care of it") have to think like the second
group ("leggo my microsecond"). 

Later,
Andrew Mullhaupt