避免在循环中串联字符串

　　在Application或Session对象中缓存数据是一个很好的方法，但是，缓存COM对象却有严重的缺陷。在Application或Session对象中缓存经常使用的COM对象这个工作是非常吸引人的，但是很不幸，许多COM对象，包括用Visual Basic 6.0或者以前版本编写的对象组件，当存储在Application或Session对象中后，都会产生严重的瓶颈问题。
　　特别地，当组件编写得不是很轻巧时，就极可能产生瓶颈问题。一个轻型组件就是标记了ThreadingModel=Both的组件，其中合计了自由线程的排列（FTM），或者标记了ThreadingModel=Neutral（Neutral模式是Windows2000和COM＋中的新特征）。下面的组件不是轻型的：
　　Free-threaded组件（除非被集合成FTM）
　　Apartment-threaded组件
　　Single-threaded组件
　　Configured components不是轻型组件，除非它们是Neutral-threaded的。Apartment-threaded组件和其他非轻型组件在页范围内工作得很好，就是说，它们是在一个单一ASP页面中创建并释放的。
　　如果缓存了非轻型组件，将会发生什么错误？在Session对象中缓存的非轻型组件将会“锁住”会话。ASP维护着一个响应请求的工作线程池，通常，新的请求被第一个可用的工作线程控制。如果一个会话被锁在一个线程中，那么请求就被迫等待到相关的线程变为可用。这里有一个类比：你前往一个超级市场，挑选了一些食品，并在3号付款台付款。从那以后，只要在那个超级市场买食品付款，你就会经常到3号付款台去，虽然其他的付款台人少些甚至没有人。
　　许多人在循环中建立一个字符串，就象下面的样子：
　　s = "<table>" & vbCrLf
　　For Each fld in rs.Fields
　　s = s & " <th>" & fld.Name & "</th> "
　　Next
　　While Not rs.EOF
　　s = s & vbCrLf & " <tr>"
　　For Each fld in rs.Fields
　　s = s & " <td>" & fld.Value & "</td> "
　　Next
　　s = s & " </tr>"
　　rs.MoveNext
　　Wend
　　s = s & vbCrLf & "</table>" & vbCrLf
　　Response.Write s
　　这存在几个问题。首先是重复的连接字符串消耗二次方的时间，而且，运行的时间与计算的字段数量也是平方的关系。下面的简单例子更清楚地说明这一点：
　　s = ""
　　For i = Asc("A") to Asc("Z")
　　s = s & Chr(i)
　　Next
　　在第1层循环时，S的值是“A”；第2层循环时，VBScript要重新分配字符串，拷贝了2个字符（“AB”）到S中；第3层循环时，需要再重新分配并且拷贝3个字符到S中。在第N层循环时，就需要重新分配并拷贝N个字符到S中。那就是1+2+3+...+N的总和，也就是N*（N＋1）/2个拷贝。
　　在上面的记录集例子中，如果有100个记录和5个字段，内部循环就要执行100*5＝500次，并且，完成所有拷贝和再分配任务的时间将接近500*500＝250，000。这还是一个适当尺寸记录集的拷贝工作。
　　在这个例子中，可以通过替换字符串连接为Response.Write（）或者行内脚本（< % =fld.Value % >）的方法提高程序性能。如果response buffering打开（也应该打开），这将很快，因为Response.Write仅仅附加数据在缓冲区的尾部，而且不需要再分配。
　　如果用JScript连接字符串，强烈建议使用“＋＝”操作符，就是说，使用s＋＝“字符串”，而不是s ＝ s＋“字符串”。