Keep a fast cache of type metadata, and use it for lookup

[gfodor]

This PR improves performance around type metadata look up by keeping a cache of various commonly needed bits of type metadata and providing a fast path to look them up in one call. It also adds a proper/fast comparer class for all dictionaries keyed by Type.

[liiir1985]

I assume that this pull request is about to improve the performance of this method, but I have a concern that you are computing the hashcode through type's full name, which could be problematic in some cases like generic type instances and byRef Types. Besides, getting FullName also needs interaction with native metadata, which costs additional CPU time. I used Type as key directly in AppDomain and didn't specify a custom KeyComparer, and didn't encounter hash collision yet, but it may need more tests. Do you have a benchmark or so which compares the performance?

[gfodor]

Ah good point re: generics/byref types on the comparer. Any other cases? Here's a profile showing some of the speed issues with the default comparer. The internal mono equals/hashcode for types is quite slow.

http://i.imgur.com/ScAv2Xe.png

The call to FullName is quite fast, and the hash code of strings is obviously trivial since it is cached. I will see how slow things are if i properly update the routine to take into account generic type parameters + byref.

[gfodor]

OK, I was unable to write a better hashcode routine (particularly for generics.) I've pushed an alternative change that now uses reference equality/reference hashcode for these dictionaries. Performance wise this is a significant win and seems safe -- some quick research shows that according to the C# spec:

There is only one System.Type object for any given type. This means that for a type T, typeof(T) == typeof(T) is always true.

and in Object.GetType https://msdn.microsoft.com/en-us/library/system.object.gettype.aspx

For two objects x and y that have identical runtime types, Object.ReferenceEquals(x.GetType(),y.GetType()) returns true.