TITLE: when is inline reasonable

(Newsgroups: comp.lang.c++.moderated, 8 Jan 2000)

MARQUARDT: Klaus Marquardt <klaus.marquardt@draeger.com>

|>  When weighting encapsulation and change migration against execution
|>  speed, it would be helpful to know a heuristic when a compiler /
|>  optimizer really uses the offer to inline member function code.
|>
|>  For trivial one-liners I guess the compiler would inline. For complex
|>  functions it would not.
|>  But what about functions of about 4-5 lines that are executed rather
|>  frequently?  Will this exhibition of implementation details (and
|>  possible export of internal constants) really help increasing
|>  performance?
|>
|>  Any experiences or references are welcome.

KANZE: kanze@gabi-soft.de (James Kanze)

Any experience would be extremely application and compiler dependant.
In most serious shops, inlining anything is forbidden until the profiler
says otherwise.  Personally, I tend to only use inlining for direct
forwarding functions or in "local" classes (the implementation class in
a Cheshire cat, for example).  People doing serious number crunching
probably would use it significantly more.

Note too that you don't necessarily have to declare a function inline
for the compiler to generate it inline.  At least one compiler I've
heard of uses profiling information to decide what to inline -- and it
can inline functions even when the definition is not present in the same
module.

On the other hand, unless exported (and I know of no compiler which
supports export to date), you pretty much have to expose templated
functions as if they were inlined, so you might as well go to town.



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