Hi,

I have gotten some code where alot of the functions in most of the
objects are inlined. If I try to create to many objects 10K plus, I
need to increase the stack for it to run.

My question is? Can you inline to much and what are the memory
ramifications if you inline to much. Does it use stack when inlining?

Can you explain how inline works i.e. memory. I am using MS Visual C++
6.0

David...

---

Clarification of Question by davidlpotter-ga on 23 Sep 2003 14:39 PDT

Hi,

Is what I meant by inline objects are that in this code I got, he
inlines alot of function's including the constructor in some case's.

I did not understand why you would do this? I also felt you could slow
down the code with to many inline's, by not letting the compiler
optimize etc.

David..

Hello Davidlpotter,

Let me recap the questions, provide specific answers, as well as
describe the general approaches used by the compiler and optimization
techniques.

Q1: Can you inline too much?
A1: Yes. Like any other technique, it can be used incorrectly.

Q2: What are the memory ramifications if you inline too much?
A2: Another term for this is "code bloat". Each time an inline
function (or method) is referenced, a complete copy of its code will
be included at that point of the application. For small functions, the
function is smaller than the code to call the function - this actually
saves code. For larger functions, the application size grows.

Q3: Does it use stack when inlining?
A3: No. It increases the amount of code which is accounted for
separately.

Q4: Why would you do this?
A4: There is a misconception that inline functions are always faster
than regular functions.

Note also that in C++, the functions defined (not just declared) in
the class declaration, it will be inlined. Using an example from "The
C++ Programming Language" by Stroustrup:
  int b;
  struct x {
    char* f() { return b; }
    char* b;
};
is equivalent to
  int b;
  struct x {
    char* f();
    char* b;
};
inline char* x::f() { return b; } // moved

This is most often seen with constructors and destructors. If you have
nested declarations like this - the constructor and destructor
functions get very large. Some companies have coding guidelines that
prevent that - for example
  http://www.chris-lott.org/resources/cstyle/Ellemtel-rules-mm.html#rule21
is a coding standard originally developed for Ellemtel.

Separately - let me summarize the use of code segments, data segments,
the heap, and stack. A program is often structured like...

  - code - 
  - static data -
  - heap - (growing up)
  - stack - (growing down)

The code and static data are laid out by the compiler / linker and
don't change during run. The heap is used for dynamically allocated
items - in C++ using new. The stack is used for local variables -
declared in a function, or parameters passed to functions (and the
return value). If you declare or pass large objects to functions, you
can get unexpected stack growth.

If you are concerned about stack usage of functions, set breakpoints
using the debugger - examine the registers (stack pointer) to see how
much it changes with a set of calls. If you are concerned about
performance - measure it.

The following are a few other references on inline, code bloat, and
optimization:

A general description of techniques that result in extra code.
  http://www.diamand.org/bloat.html

A Microsoft reference on optimization in Visual C++
  http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dv_vstechart/html/vctchoptimizingyourcodewithvisualc.asp

Thinking in C++ (specifics on inline)
  http://www.codeguru.com/cpp/tic/tic0103.shtml

C++ Optimization Techniques (link to inline function comments); note
that this recommends measuring performance when using inline.
  http://www.tantalon.com/pete/cppopt/final.htm#InlineFunctions

A number of additional references can be found using search phrases
such as:
  code bloat inline visual c++
  code bloat inline
  ellemtel coding standard
  visual c++ optimization

Let me know if you need further information or examples.

  --Maniac

I'm not sure what an inline object is (if you can post a teeny code
sample, that might help us to get our terms straight).

Inlining functions is a common tactic for making code faster, but it's
often abused.  On a modern compiler like MSVC, it's very very rarely
needed. MSVC is very smart, and makes function calls pretty efficient
without hints from the sourcecode.

When you inline a function (or a method in C++) the compiler emits a
copy of the machine code for that function for _each_ time it's
referenced (as opposed to just once, for normal functions/methods). 
This cuts down the time to call the function, and the time for the
function to return.  For all but the most hard-case DSP, control,
raytrace, etc. application then this overhead is _trivial_ when
compared with the total runtime of your program.

So, inlined functions actually contribute to the body of code (what's
called "the text segment"), which is distinct from the heap and the
stack (but it's still ram).  Call a function 1000 times and there will
be 1000 copies in the text segment.

VC contains a program called DUMPBIN.EXE, which shows the size of the
text segment in any executable.

Now the automatics (the non-static variables) inside an inline
function are just the same as their cohorts in a non-inline function,
and they go on the stack (but only for the duration in which that
function runs - once it terminates the stackframe is popped and the
space reclaimed).

Assuming you're allocating your objects with new, then that memory
comes from the heap.

Back to inline. Don't.  If it's someone else's code, #define it away. 
It use _almost_ always indicates premature optimisation.  In addition
to its bloating your text segment, it ruins the processor's
code-caching, and thus could easily result in your program actually
running slower (if abused in the proflegate manner you describe).

ooh, i should clarify that - call a function in a thousand DIFFERENT
PLACES and you'll get 1000 copies.  Naturally, call it 1000 times in a
single for loop and there's only 1 copy of the function in the text
segment, naturally.

Frankly, I think your problem probably isn't inlining (if
stack-exhaustion is the issue).  I bet someone is allocating some
gigantic objects as automatics.  It'll take some stern code-reviewing
and analysis to figure out what you can put as static (the ideal) or
(if you're carefull) on the heap.