Re: Bloat

[Thor Lancelot Simon <tls%rek.tjls.com@localhost>]

On Wed, Jan 28, 2009 at 09:43:59PM -0500, Allen Briggs wrote:
> 
> And it's not quite that simple and straightforward in some ways.
> For vax (I think) inline makes a lot of sense because there's a
> significant function call overhead.  For ARM (and others?), inlining
> can be bad in some cases because it increases the code size, which
> can increase the memory footprint of the code and the number of
> instruction cache misses.  In that case, functions (and non-unrolled
> loops) *can* actually be better.

I also think that inlines in header files, for many simple purposes
(e.g. get/set accessors for the datastructures defined in those files)
are better than at least two common alternatives:

1) Macros to do the same thing.  These do nothing but confuse the debugger
   and prevent type-checking.

2) "method" function pointers in those same datastructures, which cause a
   jump through a pointer, which can really wreck performance.

If it's not important to keep the structure definitions and the utility
code close together, then, sure, such functions needn't be inline.  But
in many simple cases of implementation-hiding, where, for example, an
inline function just returns a member of a structure or union, even a
normal function call, on almost every architecture, will at least double
the cost.

I generally think if it's more than about 5 lines of code, it really
really should *not* be an inline.

Thor