I know there is some positive aspects of inheritance, but I don't know negative runtime impacts of inheritance? Can anybody tell me about that, thanks!
Asked
Active
Viewed 1,229 times
8 Answers
4
- Large inheritance based systems usually uses more memory and have worse data layout than composition based systems, this has a runtime cost in terms of speed due to how the cache behaves ( you want everything related to be as tightly packed as possible ).
- Virtual function calls requires a trip to a virtual function table in order to retrieve the correct function to call, this can be costly due to cache behavior, the vtable might be far from the calling function.
- Multiple inheritance increases the cost of virtual function calls further, as first an offset might need to be computed in order to get the correct vtable.
- If you're using RTTI, then you'll usually see additional data at a fixed location in relation to the vtable. This affects the vtable locality, which once again prohibits the cache.
Ylisar
- 4,293
- 21
- 27
3
If a base class contains virtual functions then instances of it and its descendants will each have a pointer to a virtual function table, increasing their memory footprint by the size of one pointer. Calls to virtual functions will have an extra level of indirection compared to non-virtual functions, so there is a small call time cost there.
Otherwise, there is no negative impact. Deriving one class from another but not using polymorphism (so, no virtual functions, always calling methods through pointers to the derived class) has no cost over a class with no parent.
Update: I have addressed the performance impact of inheritance here. Other answers have more to say on OO-correctness.
RobH
- 3,199
- 1
- 22
- 27
-
–1 … Deriving one class from another but not using polymorphism makes no sense whatsoever from an OO perspective (there’s the code reuse aspect but that’s actually an anti-pattern in OOP – use composition, not inheritance!) so this answer is misleading. It’s also wrong because it claims that there is no negative impact in using inheritance. Clearly, that’s wrong (again, that’s why we have the rule to use composition instead of inheritance) because it increases tight coupling, breaks encapsulation and consequently leads to more complex designs. – Konrad Rudolph Oct 21 '11 at 07:41
-
@Konrad: if deriving one class from another without polymorphism made no sense, there would be nothing but pure interface inheritance. A good use of inheritance without polymorphism is with mixins. – Don Reba Oct 21 '11 at 08:35
-
@Don As I said in my comment, you can (and should) use composition for that (unless of course the language supports real mixins like in Ruby or D). The tight coupling imposed by inheritance otherwise makes this unadvisable. Your claim about “there would be nothing but pure interface inheritance” is extreme, but the thrust is definitely right. After all, this is why Java and .NET decided against multiple inheritance in the first place. – Konrad Rudolph Oct 21 '11 at 09:11
-
@Konrad, I think you are being too idealistic, but I won't argue here. Your -1 for the answer being wrong is still valid. – Don Reba Oct 21 '11 at 09:43
-
Naturally, I would disagree. OP asked for negative effects of inheritance, and I have chosen to interpret that as a request for negative performance impact. @Konrad's opinion of whether it is legitimate or not to create derived classes without polymorphism is irrelevent. – RobH Oct 21 '11 at 14:16
-
@DonReba - From a performance perspective I hold that my answer is correct, unless you have evidence to the contrary. You have chosen to address a different side of inheritance, where I've gone for the purely mechanical view. – RobH Oct 21 '11 at 14:19
-
+1 from me since I consider @Konrad Rudolph's position to be valid but pedantic. Achieving code reuse through composition is preferrable in many cases but there are exceptions (as there are for every rule). I think this answer points out a valid performance impact which I consider to be relevant to the question, so +1 from me. – Frerich Raabe Oct 21 '11 at 14:29
-
@RobH, inheritance places a restriction on where the data goes in memory, and restrictions always have costs. Usually it is insignificant, but sometimes it is crucial. – Don Reba Oct 21 '11 at 14:56
-
@DonReba True, insofar as a contiguous block of memory large enough for base class + derived class data would be required. However, the alternatives without inheritance would be to have one object with the same data (with no difference in footprint), or to have parts of the object scattered over the heap. I guess the latter might in some circumstance be preferable. – RobH Oct 21 '11 at 15:17
1
The only runtime impact could be performance in terms of memory and speed. Considering functionality-wise everything can be done without inheritance, the only question is how well it performs as opposed to the alternatives. That will depend on the specific scenarios you want to compare, and the complier's generated code.
tenfour
- 36,141
- 15
- 83
- 142
1
Inheritance can negatively impact data locality, which is a big deal when you have a lot of numbers to crunch. You also get less control over data layout than when you use composition, so your objects might take up more memory.
If you also use polymorphism, then you spend additional cycles on indirect function calls and get even worse data locality, as you reference virtual function tables.
Generally, the overhead cost of object-oriented programming is fairly small and you only have to think about it when you are processing large amounts of data. Check Sony's Pitfalls of Object Oriented Programming presentation — it looks at OOP performance from a game developer's perspective.
Don Reba
- 13,814
- 3
- 48
- 61
1
The benefits of using inheritance greatly outweigh the downfalls.
The first downfall is the object size in memory, which, when using virtual functions, has an extra pointer to the virtual function table.
Virtual function calls also require a few extra steps in the assembly compared to regular calls.
Non-virtual function calls cost the same in terms of performance.
Object size can also increase as an object of class A, if A is derived from B, contains all information from B. Of course, with a well-thought design, this doesn't happen, because even without inheritance, A would contain all information in B.
One more issue would be the use of dynamic_cast or static_cast, which you wouldn't encounter in an inheritance-free environment, but these can also be avoided even using inheritance.
Luchian Grigore
- 253,575
- 64
- 457
- 625
1
Since you tagged your post with C++, I'd like to add that one of the most important runtime impact when you use virtual function in C++ is related to the impossibility to expand them inline.
In fact, the heaviest performance impact is not due to the virtual function table lookup, but to the fact that the compiler cannot expand a virtual function even if you declare it as inline. This prevents an important optimization that could make your code much faster.
Daniele Pallastrelli
- 2,430
- 1
- 21
- 37
-
-
@DonReba the inline expansion of virtual function is possible only when the compiler has an actual object rather than a pointer or reference to an object: it's a rare case. – Daniele Pallastrelli Oct 21 '11 at 16:57
1
After reading the other (informative!) responses, I believe one potential negative impact wasn't mentioned yet:
Inheritance is often used to achieve polymorphy. In C++, this means that you pass references (C++ references or pointers) to the base type around, instead of passing it by value, to avoid the slicing problem. In practice, passing references around often means that the scope of an object should no longer define its life time - so people start using dynamic memory management (say, new and delete). And this can open a whole can of worms itself.
To make a long story short: very often, inheritance goes hand in hand with dynamic memory allocation, which opens a whole new class of issues.
Community
- 1
- 1
Frerich Raabe
- 90,689
- 19
- 115
- 207
0
I would think inheritance would only improve runtime. If you rewrite the code in several places that code has to be compiled that many times more.
Antarr Byrd
- 24,863
- 33
- 100
- 188