A note for those not consumed by efficiency worries (was: function calls)

[Steve Summit]

It is unfortunate that perpetual concerns about microoptimization
tend to suggest that function call overhead is unacceptable and
should be avoided.  For most programs, readability and
maintainability are far more important than efficiency, and good
modularity (accompanied by lots of function calls) is of course
an important property of a well-written, readable and
maintainable program.

I hope that the abstruse and low-level function call details
being discussed here won't discourage people from moving code to
subroutines whenever it seems appropriate.  Worrying about
register allocation and cycle shaving should be of concern only
to compiler writers.

(Remember, too, that function calls on any machine are by no
means "slow."  This discussion is splitting hairs between
"extremely fast" and "ridiculously fast;" the concerns about
having to save state in a stack frame merely indicate that it is
nontrivial to make things ridiculously fast.)

In article <14273 at lambda.UUCP> jlg at lambda.UUCP (Jim Giles) writes:

>It seems to me that if a procedure is so small that it can only find
>use for 24 (or fewer) registers, then it is small enough to be a real
>good candidate for inlining...  However, most procedures
>of any size can benefit from quite a few more registers than 24.

I'd dispute this, and I'm not even religious about keeping all of
my subroutines smaller than a page or anything.  Few of my
routines even have 24 variables, let alone 24 variables that have
good reason to be put in registers.  (On many machines, it's
better to leave a variable that's only used once or twice out of
a register, because it would take as long to save and restore the
previous register contents -- on the stack -- as it would to
access the variable "conventionally" -- on the stack.)  I
understand that a good compiler might find use for additional
registers to store intermediate values not explicitly named by
the coder, but still, 24 seems like an awful lot.  Good code,
particularly object-oriented code, has lots and lots of small
routines, but they don't all need inlining.  (A medium-sized --
i.e. small but not tiny -- routine that's called a lot shouldn't
necessarily be inlined.  Code size still matters.)

                                            Steve Summit
                                            scs at adam.mit.edu