Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!sdd.hp.com!uakari.primate.wisc.edu!crdgw1!uunet!world!iecc!compilers-sender From: mike@vlsivie.tuwien.ac.at (Michael K. Gschwind) Newsgroups: comp.compilers Subject: Is inlining evil? Keywords: optimize, design Message-ID: <9105031304.AA00625@slave.vlsivie.tuwien.ac.at> Date: 3 May 91 19:43:17 GMT References: <7524@ecs.soton.ac.uk> <1991May1.035622.25021@daffy.cs.wisc.edu> <19 Sender: compilers-sender@iecc.cambridge.ma.us Reply-To: Michael K. Gschwind Organization: Compilers Central Lines: 38 Approved: compilers@iecc.cambridge.ma.us 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 -- Send compilers articles to compilers@iecc.cambridge.ma.us or {ima | spdcc | world}!iecc!compilers. Meta-mail to compilers-request.