.NET编程中的部分效率问题

1.         父类要精简，没有必要的方法和属性不要写在上面。因为即使是私有的方法和属性，对于子类来说，虽然无法继承，但是这些内容也会存储在子类中，只是我们无法使用而已。这样就造成了子类占用了许多无谓的空间。

2.         类中的静态字段没有倍乘成本。既我们对那些在类中需要经常使用的，或是创建成本比较大的字段，要尽量用静态字段。而如果用非静态的字段，如果出现莫个类创建一万次的话，那就会创建一万个该字段。会非常影响效率。

3.         静态方法并不比实例方法性能好。因为在.NET中，无论是静态方法还是实例方法在代码段中只是存储一份，也就是不会出现上面所说的实例字段出现的倍乘问题。所以我们在编写类的时候，不用从倍乘方面考虑方法的动静态的问题。

4.         虚函数存在效率问题。因为无论是静态方法还是动态方法，在编译器中都是执行Jmp到确定的地址，而虚函数的地址是不确定的，需要后期绑定，所以对程序效率有所影响。

5.         慎用Struct类型作为参数进行传递。在编写程序的时候我们有时会考虑是用类还是用结构的问题，虽然在.NET中结构没有垃圾回收的成本（当然垃圾回收的成本也不会因为少一个类而降低多少），但是当作为参数传递时需要内存拷贝，这样的成本是比较大的。但是如果我们仅仅是在方法里使用结构，而不是作为参数进行传递则没有关系。

6.         将对象置为NULL，来诱发垃圾收集器收集是无效率的。我们常常在程序中创建某个类，使用后，在结束的位置用 xxx=null；来试图释放内存，其实常常垃圾收集器已经在该类使用后将其收集了，这样做多此一举。

7.         尽量不要自己写析构函数。由于.NET中的垃圾收集器已经很有效了，所以我们没有必要一定要亲历亲为的去写析够函数来释放我们不放心的对象或变量。而且析够函数的效率比较低，反倒会起到不好的作用。

8.         垃圾收集器虽然效率高，但是它也有“欺软怕硬”的特点。对于那些“抱团”的对象(与其他对象有纵横交错的联系，如DataSet类)，其收集的效果没有简单对象好（我们是不是可以帮它一下呢？和前面的第6点需要辨正的来看问题？）。

9.         “接口”、“委托”、“反射”这些都是晚帮定地址的，其效率都会收到影响。