|Is inlining evil? email@example.com (Michael K. Gschwind) (1991-05-03)|
|Re: Is inlining evil? hoelzle@neon.Stanford.EDU (1991-05-04)|
|Re: Is inlining evil? firstname.lastname@example.org (1991-05-04)|
|Re: Is inlining evil? email@example.com (Clark Williams) (1991-05-05)|
|Re: Is inlining evil? firstname.lastname@example.org (Marc Sabatella) (1991-05-08)|
|From:||Michael K. Gschwind<email@example.com>|
|References:||<firstname.lastname@example.org> <1991May1.email@example.com> <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
firstname.lastname@example.org || email@example.com
Voice: (++43).1.58801 8144 || Fax: (++43).1.569697
Return to the
Search the comp.compilers archives again.