I have 3 books on my shelf:

http://www.amazon.com/gp/product/0201734117/
http://www.amazon.com/gp/product/0735621632/
http://www.amazon.com/gp/product/1861006292/

These three books will cover everything you need to know to answer the
questions in this post.

You can use deep class hierarchies as much as you want but I don't know
about the performance hit.  If you have frequently constructed objects you
might look into using a custom object pool.  I use them extensively (with
Generics) in our system and it makes a noticeable difference.  You may not
notice the server application running faster but you will notice a more
consistant CPU utilization lower than constantly creating thousands of
object repetitively per second/minute/whatever.

I haven't written anything about creating a custom object pool with C# but
Oliver Sturm has and it is almost identicle to the one I came up with
(conceptually) but only slightly different implementation (8-part series):
http://www.sturmnet.org/blog/archives/2005/10/18/object-pooling8/

If I remember correctly, virtual calls are not inlined.  Regarding
Constructors: Quote from MSDN2:
(http://msdn2.microsoft.com/en-us/library/w59wc6da.aspx)

The compiler cannot inline a call to a constructor if the class has a static
constructor. The compiler cannot inline a call to any member function if the
class is a value type, has a static constructor, and does not have an
instance constructor. The common language runtime may inline the call, but
the compiler cannot.

Weak references are special objects that allow you to track references that
may have been garbage collected, without keeping a reference to it (thus
preventing garbage collection).  There aren't many implication with memory
management using WR unless you abuse it or do something wrong.  In short, WR
really help you when used correctly.  See:
http://msdn.microsoft.com/msdnmag/issues/1200/GCI2/

Keep in mind, if an object or valuetype (or array) consumes more than 80,000
bytes then the memory manager will not "defrag" the memory to allow the heap
to contain contiguous free memory.  This is for performance reasons.  I
absolutely do not know how to monitor the memory heap or memory degragger,
but I *guess* that an object holding references to other objects that
cumulatively hold more than 80,000 bytes doesn't count unless it is the
one-very-same-object.  However, you might want to keep this in mind and do
some of your own research (and benchmarking/profiling) to see what works for
you.  Using lots of valuetypes or a collection of value or a large array
will reach the 80k limit more than references of thousands of other objects
will (*I think*).  Perhaps someone from MS can confirm.

Interface methods are virtual and thus are not inlined.

I don't know.  What I do know is that a generic call is more or less a
"template" that when used for the first time against a type, a copy of it
using the specific type is created in memory and that copy is used for the
same type subsequently (I'm over simplifying the description here).  Each
different type will get a different copy.  The end result really doesn't
appear to be much more different than if it wasn't using a generic in the
first place but to specifically answer your question, I cannot be more
specific.  There is plenty of information on Generics (especially in the
ECMA spec for C# 2.0) and you alway of .NET Reflector to inspect your code
after compiling it.

That's a big story.  I don't have time to write it.  Refer to the books at
the top of this reponse.

Thanks,
Shawn