Is inlining evil?

Michael K. Gschwind<>
Fri, 3 May 91 15:04:36 MED

          From comp.compilers

Related articles
Is inlining evil? (Michael K. Gschwind) (1991-05-03)
Re: Is inlining evil? hoelzle@neon.Stanford.EDU (1991-05-04)
Re: Is inlining evil? (1991-05-04)
Re: Is inlining evil? (Clark Williams) (1991-05-05)
Re: Is inlining evil? (Marc Sabatella) (1991-05-08)
| List of all articles for this month |

Newsgroups: comp.compilers
From: Michael K. Gschwind<>
Keywords: optimize, design
Organization: Compilers Central
References: <> <> <19
Date: Fri, 3 May 91 15:04:36 MED

Preston Briggs writes:
>Obviously, inlining is not completely Evil.
>However, I think it has been over-sold and over-used.
>This is a little attempt to even the balance.

Yes, inlining can result in performance degradation, esp. cache effects
can be awful, but judicious use of inlining is a Good Thing. If you
inline (modestly) huge functions (< 10-20 % of I - cache size (?)), this
will destroy any hint of locality. Take this example of C code:

{ ...

... }

If you expand huge_function() four times in the object code, you'll
probably get lots of cache misses, whereas if you actually call a
function, you will huge_function will probably still reside in the cachw.
(on the other hand, if you have many ridiculously short functions (such as
simple C++ members), it increases locality.)

Inline functions are far superior to macros (C hackers, please don't flood
my mailbox ;-) in avoiding unwanted side effects, because they are
supposed to have identical semantics when compared to `normal' functions.


Michael K. Gschwind, Dept. of VLSI-Design, Vienna University of Technology || mike@vlsivie.uucp
Voice: (++43).1.58801 8144 || Fax: (++43).1.569697

Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.