TITLE: when is inline reasonable (part ii)

(Private correspondence, 24 Feb 2000)

AUTHOR: David R Tribble [mailto:david@tribble.com] 

As inlining is mostly used for optimization, the usual guidelines and
caveats about optimization apply.

First rule of optimization:
  Don't do it.

Second rule of optimization (for experts only):
  Don't do it yet.

Bear in mind that the compiler can almost always generate more efficient
code than you can.  That's one reason that the 'register' keyword is
pretty much obsolete nowadays.

Also bear in mind that allowing the compiler to inline a function prevents
you from replacing that function in a future revision of your library
without requiring your customer to recompile his code.  The use of
lightweight proxy and forwarding functions provides benefits in
forward-compatibility while losing a little in speed, but this is
generally considered a fair trade-off.

Inlined functions typically execute faster, but take up more code space
than non-inlined functions.  This might be important for applications
cramped on memory.

It's my opinion that most functions gain little by being inlined; it's as
if it's a knee-jerk reflex to inline all of the accessors and "small"
member functions of every class, when in reality very little is gained
by this.  Try comparing the actual speed-up you get by inlining many
functions (that don't require inlining for some other reason); the gains
in speed are typically not that impressive.  Add to that the extra effort
needed to write the inline functions and the extra maintenance effort
they create, and it's easy to see that many times they are just not
worth it.

By far the most important observation to make is the fact that I/O
operations outweigh all other (computational) operations combined, being
at least two or three orders of magnitude slower.  The difference in
calling an inlined function a million times versus calling its non-inlined
equivalent could very well be overshadowed by a single printf() or
window redrawing call.

As always, there are exceptions to the rule.  Templates are one,
especially lightweight template functions that call common implementation
class functions to do all of their actual work.  This kind of interface
really is best written using inline functions (at least until the
'export' keyword becomes more popular).  And computationally intensive
applications that demand high speed, such as real-time video image
processing, really do stand to benefit from carefully inlined code.



_______________________________________________
cpptips mailing list
http://cpptips.hyperformix.com