This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: penalty for member functions?

> Is there a general runtime penalty for object oriented programing?
> (May be due to shortage of registers?)

Without a detailed analysis, it is hard to tell what the problem is.
Possible causes are:

- access to the virtual table (for virtual calls)
- the need to pass an implicit argument to each function (this)
- invocation of implicit functions (such as ctors and dtors)
- optimization problems

In the last category, a known problem of g++ is the difficulty of
keeping object state in registers. gcc knows that it has to write back
modifications of structure state if the address of the state was
taken, to support code like

int *x;
int foo()
  int y = 1;
  y = &x;
  return y;

void bar()
  *x = 2;

If the address of y is never taken, the compiler statically knows that
foo returns 1. Since the address is taken, it needs to put the 1 on
the stack (into y), and later retrieve the value of y.

In C, this optimization is quite signification. In C++, invoking any
method means that the address of the object is taken (since it is
passed as 'this'). As a result, anybody could have addresses to local
objects, and all object state has to leave in real memory most of the

In some cases, g++ could do better. E.g. if the object lives on the
stack, g++ usually knows what type it has, and could invoke virtual
functions directly. In some cases, they may turn out as inline, and
g++ would know whether the address of the object is kept anywhere.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]