> it boils down to optimization.  MALLOC should be used in 'critical
> paths'.  How you do determine if something's a critical path?
> "profile" is one good answer.
> 
> I just about always use malloc(), unless i have good reason to believe
> that a piece of code would be used sufficiently frequently that the
> inlining would be of significant benefit.

Yes, this is a classic quantity-of-inline-code versus subroutine-call-overhead
tradeoff.  I've actually measured the impact of MALLOC() versus malloc(),
and FREE() versus free(), in a bit of code which did memory allocation quite
frequently (actually in a radix trie routing table implementation to
replace the Berkeley version).  What I found is that MALLOC() wins measureably
over malloc() in the case where the size of the thing you are allocating
is known at compile time, such that the BUCKETINDX() macro expansion can
be compiled to a constant.  In this case the amount of code generated inline
is relatively modest, and the normal allocation using MALLOC() not only
avoids the function call but also only executes a small number of instructions
inline.  When allocating a variable length item, however, MALLOC() almost
never seemed worth it since you ended up generating a pretty hefty chunk
of code inline, but got no significant speedup in return compared to just
calling malloc() directly.  FREE() versus free() was more of a wash, the
speedup was detectable but not substantial, and you paid a fair chunk of
inline code expansion for this.

So my rule of thumb for frequently executed sections was to use MALLOC()
if a constant-sized item was being allocated, and malloc() otherwise.  FREE()
only seemed useful if it was a section where speed was essential and no
cost was too high, and since I never wrote a code section like this I always
used free().

Dennis Ferguson