Virtual vs Interface poco, what's faster?

Question

I am maintaining an application which has been designed like this:

messy code --abuses--> simplePoco (POCO data capsule)

The data capsule is a simple class with lots of getters and setters (properties) It uses a DI framework and consistently use the IoC container to provide instances of the data capsule (lucky me!).

The problem is, I need to introduce a "change notification" mechanism into simplePoco

messy code --abuses--> simplePoco 
               |
               V
         changes logger,
         status monitor
     (I wanna know about changes)

I have a few options:

• Introduce an IPoco and modify the messy code, so that I can have simplePoco for the speed or notifyingPoco when I want change notification (selectively slow)? or ...

• Make everything virtual and roll my own custom notifyingPoco class on top of simplePoco (even slower)?

• design patterns that I do not know?

It is a client/server system but I'm just modifying the server part so if possible, I'd rather not touch the messy code or the client code (there are serializers and reflections and scary ninja stuffs...) as to not accidentally break anything.

Would using an interface prevents JIT from inlining the calls to getter/setter?

What's the best way to go considering that simplePoco instances are heavily abused?

Answer 1

Any kind of virtual call (whether on interface or directly on a class - all interface calls are virtual!) will not be inlined by CLR JIT. That said, interface calls are slightly slower because they must always go through the potentially-remoted/proxied path, and because they have to shift this-pointer to point at the beginning of the class before entering the body of the function. Virtual calls directly on class members never have to do the shift, and, unless the class is derived from MarshalByRefObject, do not hit the proxying checks.

That said, performance differences between these two are very minor, so you should probably ignore them and focus on cleanliness of design and ease of implementation instead.