一 String和StringBuilder
少量的字符串操作不宜采用StringBuilder。
由于string是不可变得对象，对于string的叠加，每次操作都会生成一个新的string对象。所以针对大量string的操作时，我们会采用StringBuilde。但似乎很多人都知道这一点，所以只要字符串相加，不管三七二一都用StringBuilder。其实这是个误区，在这里要注意"大量"一词，少量的字符串操作用StringBuilder反而得不偿失。
比如下面的两种写法：
string sql = "insert into table (,,,)";
sql += " values ('')";和
StringBuilder sb = new StringBuilder();
sb.Append("insert into table (,,,)");
sb.Append(" values ('')");
string s = sb.ToString();宜采取第一种写法。因为只有两个字符串的相加，谈不上大量。如果用StringBuilder,最后还需要转换成string,结果性能反而差一些。
二 慎用异常
由于程序抛出一个异常，就会创建一个异常对象，然后应用程序会在Catch块中捕获该异常，造成性能影响非常大。
比如：
int OrderID;
try
{
OrderID = Convert.ToInt32(this.txtOrderID.Text);
}
catch(Exception e)
{
OrderID = .
}
这样的代码很不合适，造成的性能开销非常大。应该在客户端写js代码先去验证txtOrderID是否符合要求。
三 关于Session, Request
Session:
很多人喜欢用Session来保存持久对象的值。 但是当你的程序部署在多台服务器上做负载均衡时，可能会得不到Session保存的变量的值。 另外，由于Session是服务器端的内建对象，每开启一个Session对象，都在服务器上占用一些资源。
Request:
在页面间传值取值时，看到很多人都这么写代码：
string CustomerName = this.Request["txtCustomerName"].ToString();
其实后面的ToSTring()多此一举。this.Request["...."]本来就是string类型的，不必再去ToString()一下。
二 慎用异常
由于程序抛出一个异常，就会创建一个异常对象，然后应用程序会在Catch块中捕获该异常，造成性能影响非常大。
比如：
int OrderID;
try
{
OrderID = Convert.ToInt32(this.txtOrderID.Text);
}
catch(Exception e)
{
OrderID = .
}
这样的代码很不合适，造成的性能开销非常大。应该在客户端写js代码先去验证txtOrderID是否符合要求。
三 关于Session, Request
Session:
很多人喜欢用Session来保存持久对象的值。 但是当你的程序部署在多台服务器上做负载均衡时，可能会得不到Session保存的变量的值。 另外，由于Session是服务器端的内建对象，每开启一个Session对象，都在服务器上占用一些资源。
Request:
在页面间传值取值时，看到很多人都这么写代码：
string CustomerName = this.Request["txtCustomerName"].ToString();
其实后面的ToSTring()多此一举。this.Request["...."]本来就是string类型的，不必再去ToString()一下。