Lawrence Kirby <lknews@netactive.co.uk> writes:
[...][color=blue]
> Inlining can sle make code SLOWER because it can make executable
> code a lot larger and reduce the opportunity for caching. It also in
> effect combines smaller functions into one larger one and larger
> functions tend to be more difficult to optimise.[/color]
Larger functions are more difficult to optimize in the sense that the
optimizer has to spend more time and other resources on them (and the
increase can be much more than linear relative to the size of the
function). But combining more code into a single function can also
provide more opportunities for optimization -- and the end result
might actually be a smaller function with better cache behavior.
For example, given a function like:
void func(int n)
{
if (n >= 0) {
do_something(n);
}
else {
do_something_else(n);
}
}
there's not a lot that can be done to optimize it -- but if its
inlined from a call like
func(42);
or even
func(some_unsigned_int_object);
the optimizer can reduce the call to
do_something(n);
This is, of course, an artificial example designed to support my point.
Finally, the first law of program optimization still applies:
Don't do it.
The second law, for advanced programmers only, is:
Don't do it yet.
(I didn't originate these; I'm not sure who did.)
--
Keith Thompson (The_Other_Keith)
kst-u@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.
