I remember reading about that too a while ago, I can't remember really
where, it
could have been off a webpage from Microsoft. Here it is stated in
CodeProject by
someone;
http://www.codeproject.com/KB/cs/abstractsvsinterfaces.aspx.
Speed:
Interface: Requires more time to find the method in the corresponding
Class.
Abstract: Fast.
Al when I first read this a while ago I took it for face value as I
wouldn't know
how to challenge it. After reading Peter's and Arne's responses, maybe
the quote
above from the CodeProject website is also saying Interface: Fast...????
Of course
how much (more) time???
I really have no idea what the author is trying to state there.
Unfortunately, while the article has a number of very good, useful points,
those are undermined by imprecision and vagueness in other parts of the
discussion.
I find myself wondering if by "Speed", the author is describing code
maintenance, though even there the idea that it's harder to find the
implementation of an interface in a class than to find the implementation
of abstract members doesn't really make any sense either.
In terms of performance, the very first comment to the article does a fine
job debunking any claims of speed differential. The commenter does point
out that accessing fields is faster in abstract classes, but only because
interfaces can't have fields; in an interface, access to a field always
has to go through a virtual property, which can't be inlined and suffers
the infinitessimal overhead of a virtual method call (a non-virtual
property with a trivial getter could be inlined, and would most likely
perform as well as a field...but again, interfaces can't have non-virtual
properties).
Basically, it's simply not true that an abstract class is faster, in the
sense of execution performance, than an interface. It's probably not
faster in any other sense either.
Pete
