Xref: utzoo comp.lang.c:27006 comp.lang.misc:4505 Path: utzoo!attcan!uunet!husc6!encore!bu.edu!bloom-beacon!scs From: scs@athena.mit.edu (Steve Summit) Newsgroups: comp.lang.c,comp.lang.misc Subject: A note for those not consumed by efficiency worries (was: function calls) Message-ID: <1990Mar17.190858.13930@athena.mit.edu> Date: 17 Mar 90 19:08:58 GMT References: <29509@amdcad.AMD.COM> <14273@lambda.UUCP> Sender: news@athena.mit.edu (News system) Reply-To: scs@adam.mit.edu (Steve Summit) Organization: Massachusetts Institute of Technology Lines: 45 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@lambda.UUCP> jlg@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@adam.mit.edu