关于反射的效率问题
反射效率如何，在IDE中常常进行的文件引用是否就是进行了反射的处理？

我感觉反射效率也不是很低，难道是我的错觉？

------解决方案--------------------
早先据说2002版本时反射的效率相对低.
------解决方案--------------------
如果一个类型已经在内存中了，那么反射的效率降低的会小一些，否则就要关系到程序集的加载、类型加载、类型查找等问题。
即使已经在内存中了，毕竟反射多了很多的执行路径，其效率会降低是自然的。显然，.NET自己使用了大量的反射。
------解决方案--------------------
抄来的
Reflection Performance
Reflection is an extremely powerful mechanism because it allows you to discover and use
types and members at run time that you did not know about at compile time. This power does
come with two main drawbacks:
• Reflection prevents type safety at compile time. Since reflection uses strings heavily, you
lose type safety at compile time. For example, if you call Type.GetType( "Jef "); to ask
reflection to find a type called "Jef " in an assembly that has a type called "Jeff, " the code
compiles but produces an error at run time because you accidentally misspelled the type
name passed as the argument.
• Reflection is slow. When using reflection, the names of types and their members are not
known at compile time; you discover them at run time by using a string name to identify
each type and member. This means that reflection is constantly performing string
Chapter 22: Assembly Loading and Reflection 555
searches as the types in the System.Reflection namespace scan through an assembly 's
metadata. Often, the string searches are case-insensitive comparisons, which can slow
this down even more.
Invoking a member by using reflection will also hurt performance. When using reflection to
invoke a method, you must first package the arguments into an array; internally, reflection
must unpack these on to the thread 's stack. Also, the CLR must check that the arguments are
of the correct data type before invoking a method. Finally, the CLR ensures that the caller has
the proper security permission to access the member being invoked.
For all of these reasons, it 's best to avoid using reflection to access a member. If you 're writing
an application that will dynamically discover and construct type instances, you should take
one of the following approaches:
• Have the types derive from a base type that is known at compile time. At run time, construct
an instance of the derived type, place the reference in a variable that is of the base
type (by way of a cast), and call virtual methods defined by the base type.
• Have the type implement an interface that is known at compile time. At run time, construct
an instance of the type, place the reference in a variable that is of the interface type
(by way of a cast), and call the methods defined by the interface. I prefer this technique
over the base type technique because the base type technique doesn 't allow the developer
to choose the base type that works best in a particular situation.
When you use any of these two techniques, I strongly suggest that the interface or base type be
defined in its own assembly. This will reduce versioning issues. For more information about
how to do this, see the section "Designing an Application That Supports Add-Ins " beginning
on page 562 in this chapter.
------解决方案--------------------
一次try catch的开销大概是一次反射调用的1000倍以上
＝＝＝＝＝＝＝＝＝＝＝
结论何来？
＝＝＝＝＝＝＝＝＝＝＝

自己试下不就知道了？
如果是在有IO操作、网络连接、用户操作的情况下，使用反射的开销可以忽略不计的。
如果是大数据量的计算，尽量避免使用反射。