简介

     编写 ASP 页面时，开发人员实际上是创建一个格式化的文本流，通过 ASP 提供的 Response 对象写入 Web 客户端。创建此文本流的方法有多种，而您选择的方法将对 Web 应用程序的性能和可缩放性产生很大影响。很多次，在我帮助客户优化其 Web 应用程序的性能时，发现其中一个比较有效的方法是更改 HTML 流的创建方式。本文将介绍几种常用技术，并测试它们对一个简单的 ASP 页面的性能所产生的影响。

    许多 ASP 开发人员都遵循良好的软件工程原则，尽可能地将其代码模块化。这种设计通常使用一些包含文件，这些文件中包含对页面的特定不连续部分进行格式化生成的函数。这些函数的字符串输出（通常是 HTML 表格代码）可以通过各种组合创建一个完整的页面。某些开发人员对此方法进行了改进，将这些 HTML 函数移到 Visual Basic COM 组件中，希望充分利用已编译的代码提供的额外性能。尽管这种设计方法很不错，但创建组成这些不连续 HTML 代码组件的字符串所使用的方法将对 Web 站点的性能和可缩放性产生很大的影响，无论实际的操作是在 ASP 包含文件中执行还是在 Visual Basic COM 组件中执行。

     请看以下 WriteHTML 函数的代码片断。名为 Data 的参数只是一个字符串数组，其中包含一些要格式化为表格结构的数据（例如，从数据库返回的数据）。

     这是很多 ASP 和 Visual Basic 开发人员创建 HTML 代码时常用的方法。sHTML 变量中包含的文本返回到调用代码，然后使用 Response.Write 写入客户端。当然，这还可以表示为直接嵌入不包含 WriteHTML 函数的页面的类似代码。此代码的问题是，ASP 和 Visual Basic 使用的字符串数据类型（BSTR 或 Basic 字符串）实际上无法更改长度。这意味着每当字符串长度更改时，内存中字符串的原始表示形式都将遭到破坏，而且将创建一个包含新字符串数据的新的表示形式：这将增加分配内存和解除分配内存的操作。当然，ASP 和 Visual Basic 已为您解决了这一问题，因此实际开销不会立即显现出来。分配内存和解除分配内存要求基本运行时代码解除各个专用锁定，因此需要大量开销。当字符串变得很大并且有大块内存要被快速连续地分配和解除分配时，此问题变得尤为明显，就像在大型字符串连接期间出现的情况一样。尽管这一问题对单用户环境的影响不大，但在服务器环境（例如，在 Web 服务器上运行的 ASP 应用程序）中，它将导致严重的性能和可缩放性问题。下面，我们回到上述代码片段：此代码中要执行多少个字符串分配操作？答案是 16 个。在这种情况下，“&”运算符的每次应用都将导致变量 sHTML 所指的字符串被破坏和重新创建。前面已经提到，字符串分配的开销很大，并且随着字符串的增大而增加，因此，我们可以对上述代码进行改进。

     有两种方法可以缓解字符串连接的影响，第一种方法是尝试减小要处理的字符串的大小，第二种方法是尝试减少执行字符串分配操作的数目。请参见下面所示的 WriteHTML 代码的修订版本。

     乍一看，可能很难发现这段代码与上一个代码示例的差别。其实，此代码只是在 sHTML = sHTML & 后的内容外面加上了括号。这实际上是通过更改优先顺序，来减小大多数字符串连接操作中处理的字符串大小。在最初的代码示例中，ASP 编译器将查看等号右边的表达式，并从左到右进行计算。结果，每次重复都要进行 16 个连接操作，这些操作针对不断增长的 sHTML 进行。在新版本中，我们提示编译器更改操作顺序。现在，它将按从左到右、从括号内到括号外的顺序计算表达式。此技术使得每次重复包括 15 个连接操作，这些操作针对的是不会增长的较小字符串，只有一个是针对不断增长的大的 sHTML。图 1 显示了这种优化方法与标准连接方法在内存使用模式方面的比较。

图 1：标准连接与加括号连接在内存使用模式方面的比较

     在特定情况下，使用括号可以对性能和可缩放性产生十分显著的影响，后文将对此进行进一步的说明。

     我们已经找到了解决字符串连接问题的快捷方法，在多数情况下，此方法可以达到性能和投入的最佳平衡。但是，如果要进一步提高构建大型字符串的性能，需要采用第二种方法，即减少字符串分配操作的数目。为此，需要使用 StringBuilder。StringBuilder 是一个类，用于维护可配置的字符串缓冲区，管理插入到此缓冲区的新文本片断，并仅在文本长度超出字符串缓冲区长度时对字符串进行重新分配。Microsoft .NET 框架免费提供了这样一个类 (System.Text.StringBuilder)，并建议在该环境下进行的所有字符串连接操作中