Is inlining evil?

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:


{ ...
      huge_function(1);
      huge_function(2);
      huge_function(3);
      huge_function(4);


... }


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.


bye,
mike




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

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