Understanding the Empty Base Optimization

http://www.informit.com/guides/content.aspx?g=cplusplus&seqNum=319

The Empty Base class optimization enables an implementation to reduce the size of a base class subobject to zero. Although it’s not required by the standard, many compilers now implement this optimization. Let’s see how the EBO works and what its impact on performance is.

Is An Empty Object Possible?

When I discussed the C++ object model a couple of years ago, I briefly touched on the issue of "empty classes". An empty class is one that contain no nonstatic data members, either directly or indirectly (i.e., inherited from a base class). Here are a few such "empty classes":

struct S 
{
 S(); //not a POD type
 ~S();
};
class A
{
 static int x; //static data members are stored outside the object
};

Many C++ programmers are surprised to discover that the size of both A and S isn’t zero. On atypical implementation, sizeof(S) and sizeof(A) equal 1. The reason for this policy is arrays. C and C++ require that arrays shall have contiguous storage, and that each element in an array shall have a unique address. To meet these two requirements, an object’s size must be at least 1 byte.

This is an opportunity to dispel two common myths about the C++ object model: member functions aren’t represented as pointers to functions or pointers to member functions inside an object. In fact, they have no representation at all inside the object. Therefore, no matter how many non virtual member functions a class has, their number doesn’t affect its size. Similarly, static data members are stored in a memory location that doesn’t belong to any object. Therefore, the presence of static data members (and of course, static member functions) doesn’t affect the object’s size either. With respect to their binary layout, S and A are identical: objects of these classes contain a 1 or more dummy bytes.

Empty with Virtual Functions

When you add a virtual destructor or any other virtual member function to a class, that class becomes polymorphic. Although the C++ standard doesn’t specify the implementation details of polymorphic objects, in practice all implementations insert into every polymorphic object an implicit data member equal to the size of a pointer. Therefore, it’s reasonable to assume that the following polymorphic classes, which contain no overt nonstatic data members, have the same size of a pointer:

struct D
{
virtual ~D();
};
class G
{
public:
virtual f(); 
};
class H: public D{};

Put differently, you can assume that:

sizeof (H) == sizeof(D)==sizeof(G)==sizeof(void*)

Strictly speaking, these classes aren’t empty because they contain an implicit data member, i.e., the vptr. What happens when any of these classes become a base class of another class?

The Empty Optimization in Action

When a strictly-empty class such as S becomes a base of another class T, you would expect that the memory block of T should first contain the suobject S, immediately followed by the subobject T. In other words, the first byte of T should be the inherited dummy byte of S, followed by any other nonstatic data members declared in T:

struct T: S
{
int x;
};

Indeed, that’s exactly what older compilers would do. They would calculate the size of T assizeof(S) + sizeof(int). On a typical 32 bit system, the result would be 5. In practice, compilers increase the size of a class so that it fits the memory alignment requirements of the target platform. A four-byte alignment implementation will therefore increase the size of T from 5 to 8. This is a serious waste of space. After all, only 50% of the space that T occupies is used for real data, whereas the remaining 50% are unused. One could argue that a waste of four bytes is no big deal. However, a typical C++ application nowadays uses containers that store, manipulate and rearrange hundreds, thousands or millions of objects. Since most containers store value objects, not pointers or references, this means that every container of T objects occupies twice the amount of memory that it really needs. That’s hardly acceptable.

Luckily, compiler vendors found an escape clause in the standard that allows them to fix this loophole. Indeed, the standard requires that the size of an object shall never be zero; it also requires that in a derived object data members of the base class(es) shall appear before user-declared data members of the derived class. However, a base class subobject isn’t considered a complete object. Therefore, it’s possible to remove the base class subobject from the derived object without violating the rules. In other words, in the object t, the offset of S and x may overlap:

T t;

This is in essence what the EBO is all about. Notice that we didn’t lose any data or code accuracy: when you create a standalone object of type S, the object’s size is still 1 (or more) as before; only when S is used as base class of another class does its memory footprint shrink to zero. To realize the impact of this saving, imagine a vector<T> that contains 125,000 objects. The EBO alone saves half a megabyte of memory!

EBO and Polymorphic Classes

T isn’t a typical example of using public inheritance though. Normally, a base class is polymorphic. What happens when you derive from an empty but polymorphic base class? Seemingly, the base class isn’t empty so the EBO shouldn’t apply. This isn’t necessarily the case though. Let’s look at two examples:

class S2: public D {}; //D is polymorphic
class T2: public D
{
public:
virtual func();
};
T2 t2;

S2 and T2 inherit from the same polymorphic base class D. The memory layout of S2 is the same as that of D, since S doesn’t introduce new non-static data members. So in a way you could see the same optimization trick used here as well, except that this time, it’s the derived class that gets optimized -- if S2 were an empty class without a base class, its size would be larger than zero. This is a trivial case though. T2 is more interesting. T2 introduces a new virtual function. It also inherits avptr from its polymorphic base class. Will T2 end up having two vptrs? Not really. The memory layout of T2 is the same as that of D. This is because new virtual members in a derived class don’t cause a new vptr to be added. Rather, the inherited vptr is simply assigned a different value (i.e., it holds the address of a different virtual table). Consequently, sizeof(T2) is the same as sizeof(D). As with the EBO, you have two subobjects (the base subobject and the derived subobject) sharing the same memory address within the complete object t2.