Does Inheritance add overhead?

  • Thread starter Thread starter Joel
  • Start date Start date
J

Joel

Given the run-time nature of dotNET I'm wondering if inheritance decreases
performance or is that resolved by the IL?

I'm designing a data access architecture and am trying to determine if I
should limit the amount of inheritance levels in the model or if that's
irrelevant (from a performance perspective, anyway).

Thanks.

</joel>
 
You might notice a slight perf difference, but not enough to catch your
notice, if at all. Just ensure you do need that many levels of inheritance
to best set up your objects. If so, go with it.

Actually, the run-time nature is a misnomer, as it does do quite a bit of
compilation in the IL step. An overly drawn out model can destroy perf even
in a fully natively compiled system, as well.

Just make sure you need the levels and you will be fine. Good design
sometimes requires inheritance to simplify maintenance.

--
Gregory A. Beamer
MVP; MCP: +I, SE, SD, DBA

************************************************
Think Outside the Box!
************************************************
 
Joel,
Given the run-time nature of dotNET I'm wondering if inheritance decreases
performance or is that resolved by the IL?
Click to expand...

I doubt that inheritance in itself has any significant impact on
performance. Calling a virtual method can be marginally slower than
calling a non-virtual one, but unless you're making lots and lots of
calls to such a method it hardly matters.

I'm designing a data access architecture and am trying to determine if I
should limit the amount of inheritance levels in the model or if that's
irrelevant (from a performance perspective, anyway).
Click to expand...

I would worry more about how it affects the design of your
application. Code tend to become more complex and harder to understand
if you have many inheritance levels.



Mattias
 
Mattias said:
Joel,




I doubt that inheritance in itself has any significant impact on
performance. Calling a virtual method can be marginally slower than
calling a non-virtual one, but unless you're making lots and lots of
calls to such a method it hardly matters.
Click to expand...

Just to add to this, once a method is virtual it doesn't matter how
deeply nested in the hierarchy a given object instance is - the virtual
call is just a call through a vtable (or similar). So, in general a
virtual call on a base object will have similar performance to a virtual
call on an object 5 levels deep in the inheritance hierarchy.

I think this was one of the original poster's concerns.

(certain optimizations, such as on sealed classes, can avoid the
indirect call)
 
If you think of code like this:

public class C1 { }
public class C2 : C1 { }
public class C3 : C2 { }
public class C4 : C3 { }
public class C5 : C4 { }
public MyClass : C5
{
...

So, your question was (if I got you right) if it mattered whether you
derived your class from C1, C5 or maybe C100, wasn't it?

You have certain costs 'per class', i.e. there's a method/interface table
and metadata for each class, but I don't think you have any per-object or
per-method costs. I think I've read somewhere that an object costs about 4
bytes for the method table/metadata pointer plus 4 bytes for the
synchronization lock (not 100% sure if this is accurate) but there are no
'per-base' costs. Also, the 'per-method' costs (in stack space/execution
time) should be constant.

On the other hand, certain methods implicitly (e.g. constructors/finalizers)
or explicitly (e.g. Dispose) call the base method's implementation. Of
course, this pattern does add a little per-base-class cost. But usually that
cost is hardly comparable to the advantages of a good design.

Hope this helps

Niki
 
Back
Top