Introspection and Reflection
I have found the CLR's reflection capabilities to be very useful for a number of scenarios.
Unfortunately, I have discovered that calling methods via reflection could be very slow as well--over 400 times as slow as a regular function call. One performance trick that I discovered is that a delegate can be constructed from a MethodInfo, by calling one of the Delegate static methods, allowing for a direct call to be made using the correct signature. This works for property accesses too, since it is possible to get a MethodInfo from a property by using the get_Property and set_Property method name.
One of the CLR guys, Chris Brumme, mentioned that reflection was undergoing a rewrite in Whidbey for performance reasons. For good reason, many tools including Visual Studio rely on reflection for many features such as designer support, debugging and Intellisense. My forays into SSCLI indicated that very little optimization work, if any, had been done for reflection. Apparently, the focus was on shipping correct V1.0 code.
Several months ago, I saw a reference to Introspection, which was described as a new faster, engine for performing Reflection on .NET classes. I was never quite sure what it was or whether it was part of the framework.
Introspection was mentioned in an MSDN Magazine, June 2004 article on FXCop. The article mentions that Introspection introduces more extensive analysis than Reflection. The FXCop SDK page adds that, among the Introspection's advantages, are multithreading, analysis of assemblies of different versions of the framework, ability to Managed Extensions for C++ executables, and non-locking behavior.
It appears that Introspection is designed for applications and tools that perform large-scale reflecting on an assembly (perhaps reading all of the metadata into memory). In such cases, reflection would need to execute quickly for good reason. So, it would not probably not provide a performance improvement for simple uses of reflection in a standard app.