Re: When to do inline expansion

John Clinton Hall writes
> How long should a function be (in number of statements) for it to be a
> reasonable speed optimization to perform inline expansion? (For
> simplicity, let's assume that the function is only called once
> throughout the code, and the source language is C.) Obviously, a
> function with 100 statements should not be expanded; however, a
> function with only 1 statement should be expanded inline.


If it is called precisely once in the program, the function should be
inlined no matter what. (Assuming full optimization is requested.) Better
C compilers will do this for static functions within a file. (MIPS' C
compiler, IBM's xlc, and the GNU C compiler for example.)


> My guess is that executing 3 to 5 statements would equal the time it
> would normally take to set up the call, perform the call, and clean up
> after the call. Comments?


It depends a lot on your goals and compiler technology. If you're shooting
for top performance on scientific codes with a trace scheduling compiler,
you will want to inline anything possible (including 100 line functions).
If you're compiling a personal computer application, you will shun
inlining for most of the code unless it makes a function smaller. (This
occurs a lot with C++. E.g. when inline functions are used as accessor
methods on an object.)


I'd hesitate to draw the complexity criterion strictly at the statement
level though. 100 repetitions of "a = 0;" is pretty easy to inline. Some
systems (notably MIPS ucode) do inlining with an intermediate
representation of the code. This gives many more opportunities to decide
if the code can be profitably inlined. (As well as allowing inlining of
library routines.)
--
Zalman Stern zalman@adobe.com (415) 962 3824
Adobe Systems, 1585 Charleston Rd., POB 7900, Mountain View, CA 94039-7900
--

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