What are the performance implications of inheriting a class vs including a ptr to an instance of the class as a member variable?

Question

I am working in a class "A" that requires very high performance and am trying to work out the implications either way.

If I inherit this new class "B", the memory profile of "A" should increase by that much.

If I include just a ptr to "B" as a member variable in "A", then would I be correct in thinking that, as long as "B" is on the heap (ie new'd up) then "A" will remain as small as it is other than the new ptr reference. Is there something else that I haven't thought of?

It is preferable architecture wise for me to inherit "B", however it may be preferable performance wise to just stick with it as a member variable.

Answer 1

You are worrying about micro-optimisation.

You should first benchmark to determine where your actual bottlenecks are. They will rarely be where you think! They are unlikely to be purely memory based (heap or other wise), and more likely to be algorithm based or constrained by the slowest component in a system (e.g. Disk).

Answer 2

Have you profiled this and determined it will be an issue? Or are you just guessing? If inheriting is preferable and cleaner, do it the way. Later, if it turns out that the other method might be faster, do that, profile both, and determine which is faster.

However, I am confused. Inheriting from things does not increase the size of the class, except those members of the base class. In fact, having a pointer-to-base and inheriting from the base have very different behaviors! How would virtual functions work?

Also, size shouldn't slow your program down. Pass by references, and use pointer container's and smart pointer's and you shouldn't see a performance loss no matter what the size.

Answer 3

From a performance only standpoint you are correct, not inheriting will reduce the size of your class and avoid virtual table lookups. However I believe you are missing a major part of designing classes. You must consider the relations between the classes. If it makes design sense for A to inherit from B then you should probably do it. Perhaps and A and B should both reify an interface? Or you can use composition, which means you own B, and delegate to it. Composition is usually favorable over inheritance. You need to be aware of your choices and evaluate your options on more than just performance.

Answer 4

I believe inheritance would be the best case here, but every situation is different so here's the pros and cons of each choice.

Inheriting

• Usually requires virtual destructors, this causes a slight overhead during deletion of the object, and increases the size by a 'pointer' (this 1 pointer is used by all virtual objects, so it makes it a lot cleaner)
• Allows you to override a function so that it acts correctly for your object even when it is cast to the 'base' class. (Note: This does invoke a small overhead when calling the function)
• The size of the class increases by the size of the 'base'.
• Any 'base' functions that aren't virtual have NO overhead for calling them.
• Generally a lot cleaner (so long as it makes sense to inherit)

Pointing to "base" class

• Requires you to dereference the pointer to the 'base' class everytime you want to call one of its functions (i.e. every 'base' function has overhead)
• Impossible to override functions properly (so calling them on the 'base' class invokes the one in the container of the base) without using function pointers (which is possibly more overhead than virtual functions)
• Requires separate allocations for both of the allocations, which usually have quite severe performance AND memory implications (allocating is slow, and usually allocations are aligned to a certain boundary, increasing their size, as well as storing extra information so the block can be properly deallocated).
• Allows you to NOT allocate the base class, saving memory in that instance
• Allows you to change what the 'base' class even after you have created it.

Really, I think that as an optimization, this is probably one of the least significant items to investigate. Usually a small change to an algorithm (such as adding in early escapes) will make an astronomical difference compared to this sort of optimization. What should guide this decision is the structure of the program, and on that note, I think the best advice I can give you is this:

Say, out-loud, the relationship the classes have, if its "Class A is a Class B" then you should inherit. If you say "Class A has a Class B" then you should keep a pointer within Class A to Class B.