.NET Framework 开发员指南 开发高性能的 ASP.NET 应用程序请参见
下面的指南列出特定的技术，您可以使用这些技术确保所编写的代码达到可接受的性能级别。 当不使用会话状态时禁用它。并不是所有的应用程序或页都需要针对于具体用户的会话状态，您应该对任何不需要会话状态的应用程序或页禁用会话状态。
若要禁用页的会话状态，请将 @ Page 指令中的 EnableSessionState 属性设置为 false。例如，<%@ Page EnableSessionState="false" %>。 注意 如果页需要访问会话变量，但不打算创建或修改它们，则将 @ Page 指令中的 EnableSessionState 属性设置为 ReadOnly。
还可以禁用 XML Web services 方法的会话状态。有关更多信息，请参见使用 ASP.NET 和 XML Web services 客户端创建的 XML Web services。 若要禁用应用程序的会话状态，请在应用程序 Web.config 文件的 sessionstate 配置节中将 mode 属性设置为 off。例如，<sessionstate mode="off" />。 仔细选择会话状态提供程序。ASP.NET 为存储应用程序的会话数据提供了三种不同的方法：进程内会话状态、作为 Windows 服务的进程外会话状态和 SQL Server 数据库中的进程外会话状态。每种方法都有自己的优点，但进程内会话状态是迄今为止速度最快的解决方案。如果只在会话状态中存储少量易失数据，则建议您使用进程内提供程序。进程外解决方案主要用于跨多个处理器或多个计算机缩放应用程序，或者用于服务器或进程重新启动时不能丢失数据的情况。有关更多信息，请参见 ASP.NET 状态管理。
避免到服务器的不必要的往返过程。虽然您很可能希望尽量多地使用 Web 窗体页框架的那些节省时间和代码的功能，但在某些情况下却不宜使用 ASP.NET 服务器控件和回发事件处理。
通常，只有在检索或存储数据时，您才需要启动到服务器的往返过程。多数数据操作可在这些往返过程间的客户端上进行。例如，从 HTML 窗体验证用户输入经常可在数据提交到服务器之前在客户端进行。通常，如果不需要将信息传递到服务器以将其存储在数据库中，那么您不应该编写导致往返过程的代码。 如果您开发自定义服务器控件，请考虑让它们为支持 ECMAScript 的浏览器呈现客户端代码。通过以这种方式使用服务器控件，您可以显著地减少信息被不必要的发送到 Web 服务器的次数。有关更多信息，请参见开发 ASP.NET 服务器控件。 使用 Page.IsPostBack 避免对往返过程执行不必要的处理。如果您编写处理服务器控件回发处理的代码，有时可能需要在首次请求页时执行其他代码，而不是当用户发送包含在该页中的 HTML 窗体时执行的代码。根据该页是否是响应服务器控件事件生成的，使用 Page.IsPostBack 属性有条件地执行代码。例如，下面的代码演示如何创建数据库连接和命令，该命令在首次请求该页时将数据绑定到 DataGrid 服务器控件。
[Visual Basic]
Sub Page_Load(sender As Object, e As EventArgs)
' Set up a connection and command here.
If Not (Page.IsPostBack)
Dim query As String = "select * from Authors where FirstName like '%JUSTIN%'"
myCommand.Fill(ds, "Authors")
myDataGrid.DataBind()
End If
End Sub[C#]
void Page_Load(Object sender, EventArgs e) {
// Set up a connection and command here.
if (!Page.IsPostBack) {
String query = "select * from Authors where FirstName like '%JUSTIN%'";
myCommand.Fill(ds, "Authors");
myDataGrid.DataBind();
}
}由于每次请求时都执行 Page_Load 事件，上述代码检查 IsPostBack 属性是否设置为 false。如果是，则执行代码。如果该属性设置为 true，则不执行代码。 注意 如果不运行这种检查，回发页的行为将不更改。Page_Load 事件的代码在执行服务器控件事件之前执行，但只有服务器控件事件的结果才可能在输出页上呈现。如果不运行该检查，仍将为 Page_Load 事件和该页上的任何服务器控件事件执行处理。
在适当的环境中使用 ASP.NET 服务器控件。检查您的应用程序代码以确保对 ASP.NET 服务器控件的使用是必要的。即使它们非常易于使用，但是服务器控件并不总是完成任务的最佳选择，因为它们会使用服务器资源。在许多情况下，一个简单的呈现或数据绑定代入就可以完成任务。下面的示例演示了这样一种情况：使用服务器控件不是将值代入发送到客户端的 HTML 的最有效方式。每个方法都发送将由请求浏览器显示的图像的路径，但是使用服务器控件并不是最有利的方法，因为 Page_Load 事件要求调用服务器以进行处理。相反，请使用呈现语句或数据绑定表达式。
[Visual Basic]
<script language="VB" runat="server"> Public imagePath As String
Sub Page_Load(sender As Object, e As EventArgs)
'...Retrieve data for imagePath here....
DataBind()
End Sub</script><%--The span and img server controls are unecessary.--%>
The path to the image is: <span innerhtml='<%# imagePath %>' runat="server"/><br>
<img src='<%# imagePath %>' runat="server"/><br><br><%-- Use data binding to substitute literals instead.--%>
The path to the image is: <%# imagePath %><br>
<img src='<%# imagePath %>' /><br><br><%-- Or use a simple rendering expression...--%>
The path to the image is: <%= imagePath %><br>
<img src='<%= imagePath %>' />[C#]
<script language="C#" runat="server"> public String imagePath;
void Page_Load(Object sender, EventArgs e) {
//...Retrieve data for imagePath here...
DataBind();
}</script><%-- The span and img server controls are unecessary...--%>
The path to the image is: <span innerhtml='<%# imagePath %>' runat="server"/><br>
<img src='<%# imagePath %>' runat="server"/><br><br><%-- Use data binding to substitute literals instead...--%>
The path to the image is: <%# imagePath %><br>
<img src='<%# imagePath %>' /><br><br><%-- Or use a simple rendering expression...--%>
The path to the image is: <%= imagePath %><br>
<img src='<%= imagePath %>' />还有许多其他情况，在这些情况中呈现或数据绑定比使用服务器控件更有效，甚至是在使用服务器控件模板时。但是，如果要以编程方式操作服务器控件的属性、处理服务器控件事件或利用视图状态保存，则使用服务器控件是适当的。 只在必要时保存服务器控件视图状态。自动视图状态管理是服务器控件的功能，该功能使服务器控件可以在往返过程上重新填充它们的属性值（您不需要编写任何代码）。但是，因为服务器控件的视图状态在隐藏的窗体字段中往返于服务器，所以该功能确实会对性能产生影响。您应该知道在哪些情况下视图状态会有所帮助，在哪些情况下它影响页的性能。例如，如果您将服务器控件绑定到每个往返过程上的数据，则将用从数据绑定操作获得的新值替换保存的视图状态。在这种情况下，禁用视图状态可以节省处理时间。
默认情况下，为所有服务器控件启用视图状态。若要禁用视图状态，请将控件的 EnableViewState 属性设置为 false，如下面的 DataGrid 服务器控件示例所示。 <asp:datagrid EnableViewState="false" datasource="..." runat="server"/>您还可以使用 @ Page 指令禁用整个页的视图状态。当您不从页回发到服务器时，这将十分有用： <%@ Page EnableViewState="false" %>注意 @ Control 指令中也支持 EnableViewState 属性，该指令允许您控制是否为用户控件启用视图状态。
若要分析页上服务器控件使用的视图状态的数量，请（通过将 trace="true" 属性包括在 @ Page 指令中）启用该页的跟踪并查看 Control Hierarchy 表的 Viewstate 列。有关跟踪和如何启用它的信息，请参见 ASP.NET 跟踪。 使用 HttpResponse.Write 方法进行字符串串联。该方法提供非常有效的缓冲和连接服务。但是，如果您正在执行广泛的连接，请使用多个 Response.Write 调用。下面示例中显示的技术比用对 Response.Write 方法的单个调用连接字符串更快。
[C#]
Response.Write("a");
Response.Write(myString);
Response.Write("b");
Response.Write(myObj.ToString());
Response.Write("c");
Response.Write(myString2);
Response.Write("d");[Visual Basic]
Response.Write("a")
Response.Write(myString)
Response.Write("b")
Response.Write(myObj.ToString())
Response.Write("c")
Response.Write(myString2)
Response.Write("d")除非有特殊的原因要关闭缓冲，否则使其保持打开。禁用 Web 窗体页的缓冲会导致大量的性能开销。
不要依赖代码中的异常。因为异常大大地降低性能，所以您不应该将它们用作控制正常程序流程的方式。如果有可能检测到代码中可能导致异常的状态，请执行这种操作。不要在处理该状态之前捕获异常本身。常见的方案包括：检查 null，分配给将分析为数字值的 String 一个值，或在应用数学运算前检查特定值。下面的示例演示可能导致异常的代码以及测试是否存在某种状态的代码。两者产生相同的结果。
下面的指南列出特定的技术，您可以使用这些技术确保所编写的代码达到可接受的性能级别。 当不使用会话状态时禁用它。并不是所有的应用程序或页都需要针对于具体用户的会话状态，您应该对任何不需要会话状态的应用程序或页禁用会话状态。
若要禁用页的会话状态，请将 @ Page 指令中的 EnableSessionState 属性设置为 false。例如，<%@ Page EnableSessionState="false" %>。 注意 如果页需要访问会话变量，但不打算创建或修改它们，则将 @ Page 指令中的 EnableSessionState 属性设置为 ReadOnly。
还可以禁用 XML Web services 方法的会话状态。有关更多信息，请参见使用 ASP.NET 和 XML Web services 客户端创建的 XML Web services。 若要禁用应用程序的会话状态，请在应用程序 Web.config 文件的 sessionstate 配置节中将 mode 属性设置为 off。例如，<sessionstate mode="off" />。 仔细选择会话状态提供程序。ASP.NET 为存储应用程序的会话数据提供了三种不同的方法：进程内会话状态、作为 Windows 服务的进程外会话状态和 SQL Server 数据库中的进程外会话状态。每种方法都有自己的优点，但进程内会话状态是迄今为止速度最快的解决方案。如果只在会话状态中存储少量易失数据，则建议您使用进程内提供程序。进程外解决方案主要用于跨多个处理器或多个计算机缩放应用程序，或者用于服务器或进程重新启动时不能丢失数据的情况。有关更多信息，请参见 ASP.NET 状态管理。
避免到服务器的不必要的往返过程。虽然您很可能希望尽量多地使用 Web 窗体页框架的那些节省时间和代码的功能，但在某些情况下却不宜使用 ASP.NET 服务器控件和回发事件处理。
通常，只有在检索或存储数据时，您才需要启动到服务器的往返过程。多数数据操作可在这些往返过程间的客户端上进行。例如，从 HTML 窗体验证用户输入经常可在数据提交到服务器之前在客户端进行。通常，如果不需要将信息传递到服务器以将其存储在数据库中，那么您不应该编写导致往返过程的代码。 如果您开发自定义服务器控件，请考虑让它们为支持 ECMAScript 的浏览器呈现客户端代码。通过以这种方式使用服务器控件，您可以显著地减少信息被不必要的发送到 Web 服务器的次数。有关更多信息，请参见开发 ASP.NET 服务器控件。 使用 Page.IsPostBack 避免对往返过程执行不必要的处理。如果您编写处理服务器控件回发处理的代码，有时可能需要在首次请求页时执行其他代码，而不是当用户发送包含在该页中的 HTML 窗体时执行的代码。根据该页是否是响应服务器控件事件生成的，使用 Page.IsPostBack 属性有条件地执行代码。例如，下面的代码演示如何创建数据库连接和命令，该命令在首次请求该页时将数据绑定到 DataGrid 服务器控件。
[Visual Basic]
Sub Page_Load(sender As Object, e As EventArgs)
' Set up a connection and command here.
If Not (Page.IsPostBack)
Dim query As String = "select * from Authors where FirstName like '%JUSTIN%'"
myCommand.Fill(ds, "Authors")
myDataGrid.DataBind()
End If
End Sub[C#]
void Page_Load(Object sender, EventArgs e) {
// Set up a connection and command here.
if (!Page.IsPostBack) {
String query = "select * from Authors where FirstName like '%JUSTIN%'";
myCommand.Fill(ds, "Authors");
myDataGrid.DataBind();
}
}由于每次请求时都执行 Page_Load 事件，上述代码检查 IsPostBack 属性是否设置为 false。如果是，则执行代码。如果该属性设置为 true，则不执行代码。 注意 如果不运行这种检查，回发页的行为将不更改。Page_Load 事件的代码在执行服务器控件事件之前执行，但只有服务器控件事件的结果才可能在输出页上呈现。如果不运行该检查，仍将为 Page_Load 事件和该页上的任何服务器控件事件执行处理。
在适当的环境中使用 ASP.NET 服务器控件。检查您的应用程序代码以确保对 ASP.NET 服务器控件的使用是必要的。即使它们非常易于使用，但是服务器控件并不总是完成任务的最佳选择，因为它们会使用服务器资源。在许多情况下，一个简单的呈现或数据绑定代入就可以完成任务。下面的示例演示了这样一种情况：使用服务器控件不是将值代入发送到客户端的 HTML 的最有效方式。每个方法都发送将由请求浏览器显示的图像的路径，但是使用服务器控件并不是最有利的方法，因为 Page_Load 事件要求调用服务器以进行处理。相反，请使用呈现语句或数据绑定表达式。
[Visual Basic]
<script language="VB" runat="server"> Public imagePath As String
Sub Page_Load(sender As Object, e As EventArgs)
'...Retrieve data for imagePath here....
DataBind()
End Sub</script><%--The span and img server controls are unecessary.--%>
The path to the image is: <span innerhtml='<%# imagePath %>' runat="server"/><br>
<img src='<%# imagePath %>' runat="server"/><br><br><%-- Use data binding to substitute literals instead.--%>
The path to the image is: <%# imagePath %><br>
<img src='<%# imagePath %>' /><br><br><%-- Or use a simple rendering expression...--%>
The path to the image is: <%= imagePath %><br>
<img src='<%= imagePath %>' />[C#]
<script language="C#" runat="server"> public String imagePath;
void Page_Load(Object sender, EventArgs e) {
//...Retrieve data for imagePath here...
DataBind();
}</script><%-- The span and img server controls are unecessary...--%>
The path to the image is: <span innerhtml='<%# imagePath %>' runat="server"/><br>
<img src='<%# imagePath %>' runat="server"/><br><br><%-- Use data binding to substitute literals instead...--%>
The path to the image is: <%# imagePath %><br>
<img src='<%# imagePath %>' /><br><br><%-- Or use a simple rendering expression...--%>
The path to the image is: <%= imagePath %><br>
<img src='<%= imagePath %>' />还有许多其他情况，在这些情况中呈现或数据绑定比使用服务器控件更有效，甚至是在使用服务器控件模板时。但是，如果要以编程方式操作服务器控件的属性、处理服务器控件事件或利用视图状态保存，则使用服务器控件是适当的。 只在必要时保存服务器控件视图状态。自动视图状态管理是服务器控件的功能，该功能使服务器控件可以在往返过程上重新填充它们的属性值（您不需要编写任何代码）。但是，因为服务器控件的视图状态在隐藏的窗体字段中往返于服务器，所以该功能确实会对性能产生影响。您应该知道在哪些情况下视图状态会有所帮助，在哪些情况下它影响页的性能。例如，如果您将服务器控件绑定到每个往返过程上的数据，则将用从数据绑定操作获得的新值替换保存的视图状态。在这种情况下，禁用视图状态可以节省处理时间。
默认情况下，为所有服务器控件启用视图状态。若要禁用视图状态，请将控件的 EnableViewState 属性设置为 false，如下面的 DataGrid 服务器控件示例所示。 <asp:datagrid EnableViewState="false" datasource="..." runat="server"/>您还可以使用 @ Page 指令禁用整个页的视图状态。当您不从页回发到服务器时，这将十分有用： <%@ Page EnableViewState="false" %>注意 @ Control 指令中也支持 EnableViewState 属性，该指令允许您控制是否为用户控件启用视图状态。
若要分析页上服务器控件使用的视图状态的数量，请（通过将 trace="true" 属性包括在 @ Page 指令中）启用该页的跟踪并查看 Control Hierarchy 表的 Viewstate 列。有关跟踪和如何启用它的信息，请参见 ASP.NET 跟踪。 使用 HttpResponse.Write 方法进行字符串串联。该方法提供非常有效的缓冲和连接服务。但是，如果您正在执行广泛的连接，请使用多个 Response.Write 调用。下面示例中显示的技术比用对 Response.Write 方法的单个调用连接字符串更快。
[C#]
Response.Write("a");
Response.Write(myString);
Response.Write("b");
Response.Write(myObj.ToString());
Response.Write("c");
Response.Write(myString2);
Response.Write("d");[Visual Basic]
Response.Write("a")
Response.Write(myString)
Response.Write("b")
Response.Write(myObj.ToString())
Response.Write("c")
Response.Write(myString2)
Response.Write("d")除非有特殊的原因要关闭缓冲，否则使其保持打开。禁用 Web 窗体页的缓冲会导致大量的性能开销。
不要依赖代码中的异常。因为异常大大地降低性能，所以您不应该将它们用作控制正常程序流程的方式。如果有可能检测到代码中可能导致异常的状态，请执行这种操作。不要在处理该状态之前捕获异常本身。常见的方案包括：检查 null，分配给将分析为数字值的 String 一个值，或在应用数学运算前检查特定值。下面的示例演示可能导致异常的代码以及测试是否存在某种状态的代码。两者产生相同的结果。
解决方案 »
- 急求transmitfile文件下载的应用问题
- 在配置数据库中没有找到web部件包文件<.cab>，怎么解决 150分
- 数据绑定问题的方式（长期在线高分简单问题）
- 文本框数据显示的问题
- 怎样解决一个aspx里需要存在多个form的问题
- 【╰⊙ō⊙╯】 gridview 双表头，双列头的问题 ·············
- 请问QL语句中将字段名用中括号括起来有什么作用？
- listview中添加了image控件，想通过后台添加imageurl但是不显示。
- 求助：假如dataview里面有100笔记录，怎么把前50笔读出来？
- 批 sqlserver 2000 三种分页方案
- 我怎样将添加的WEB窗体删除?
- 数据类型转换问题？
// Consider changing this...
try {
result = 100 / num;
}
catch (Exception e) {
result = 0;
}// ...to this.
if (num != 0)
result = 100 / num;
else
result = 0;[Visual Basic]
' Consider changing this...
Try
result = 100 / num
Catch (e As Exception)
result = 0
End Try// ...to this.
If Not (num = 0)
result = 100 / num
Else
result = 0
End If适当地使用公共语言运行库的垃圾回收器和自动内存管理。小心不要给每个请求分配过多内存，因为这样垃圾回收器将必须更频繁地进行更多的工作。另外，不要让不必要的指针指向对象，因为它们将使对象保持活动状态，并且应尽量避免含 Finalize 方法的对象，因为它们在后面会导致更多的工作。特别是在 Finalize 调用中永远不要释放资源，因为资源在被垃圾回收器回收之前可能一直消耗着内存。最后这个问题经常会对 Web 服务器环境的性能造成毁灭性的打击，因为在等待 Finalize 运行时，很容易耗尽某个特定的资源。
有关垃圾回收器和自动内存管理的更多信息，请参见自动内存管理。 如果有大型 Web 应用程序，可考虑执行预批编译。每当发生对目录的第一次请求时都会执行批编译。如果目录中的页面没有被分析并编译，此功能会成批分析并编译目录中的所有页面，以便更好地利用磁盘和内存。如果这需要很长时间，则将快速分析并编译单个页面，以便请求能被处理。此功能带给 ASP.NET 性能上的好处，因为它将许多页面编译为单个程序集。从已加载的程序集访问一页比每页加载新的程序集要快。
批编译的缺点在于：如果服务器接收到许多对尚未编译的页面的请求，那么当 Web 服务器分析并编译它们时，性能可能较差。为解决这个问题，可以执行预批编译。为此，只需在应用程序激活之前向它请求一个页面，无论哪页均可。然后，当用户首次访问您的站点时，页面及其程序集将已被编译。 没有简单的机制可以知道批编译何时发生。需一直等到 CPU 空闲或者没有更多的编译器进程（例如 csc.exe（C# 编译器）或 vbc.exe（Visual Basic 编译器））启动。 还应尽量避免更改应用程序的 \bin 目录中的程序集。更改页面会导致重新分析和编译该页，而替换 \bin 目录中的程序集则会导致完全重新批编译该目录。 在包含许多页面的大规模站点上，更好的办法可能是根据计划替换页面或程序集的频繁程度来设计不同的目录结构。不常更改的页面可以存储在同一目录中并在特定的时间进行预批编译。经常更改的页面应在它们自己的目录中（每个目录最多几百页）以便快速编译。 Web 应用程序可以包含许多子目录。批编译发生在目录级，而不是应用程序级。 在 Internet 信息服务 5.0 上运行 ASP.NET Web 应用程序时回收进程。默认情况下，IIS 5 上的 ASP.NET 在一个进程外辅助进程中为向它提出的请求服务。此功能已被优化以提高吞吐量。在做大量工作的页面上，进程外运行的吞吐量开销并不大（大约百分之十）。由于在进程外的辅助进程中运行 ASP.NET 有许多功能和优点，建议在生产站点上使用它。
出于保证稳定性和性能的原因，请记住应定期回收进程。经过较长的时间，泄漏的资源和错误可能影响 Web 服务器的吞吐量。但是，应当平衡定期回收和过频的回收，因为停止辅助进程、重新加载页面并重新获取资源和数据的开销可能超过回收的好处。 在使用 IIS 6.0 的 Windows Server 2003 上运行的 ASP.NET Web 应用程序不需要调整进程模型设置。 必要时调整应用程序每个辅助进程的线程数。ASP.NET 的请求结构试图在执行请求的线程数和可用资源之间达到一种平衡。已知一个使用足够 CPU 功率的应用程序，该结构将根据可用于请求的 CPU 功率，来决定允许同时执行的请求数。这项技术称作线程门控。但是在某些条件下，线程门控算法不是很有效。通过使用与 ASP.NET Applications 性能对象关联的 Pipeline Instance Count 性能计数器，可以在 PerfMon 中监视线程门控。
当页面调用外部资源，如数据库访问或 XML Web services 请求时，页面请求通常停止并释放 CPU。如果某个请求正在等待被处理，并且线程池中有一个线程是自由的，那么这个正在等待的请求将开始被处理。遗憾的是，有时这可能导致 Web 服务器上存在大量同时处理的请求和许多正在等待的线程，而它们对服务器性能有不利影响。通常，如果门控因子是外部资源的响应时间，则让过多请求等待资源，对 Web 服务器的吞吐量并无帮助。 为缓和这种情况，可以通过更改 Machine.config 配置文件 <processModel> 节点的 maxWorkerThreads 和 maxIOThreads 属性，手动设置进程中的线程数限制。 注意 辅助线程是用来处理 ASP.NET 请求的，而 IO 线程则是用于为来自文件、数据库或 XML Web services 的数据提供服务的。
分配给这些属性的值是进程中每个 CPU 每类线程的最大数目。对于双处理器计算机，最大数是设置值的两倍。对于四处理器计算机，最大值是设置值的四倍。无论如何，对于有四个或八个 CPU 的计算机，最好更改默认值。对于有一个或两个处理器的计算机，默认值就可以，但对于有更多处理器的计算机的性能，进程中有一百或两百个线程则弊大于利。 注意 进程中有太多线程往往会降低服务器的速度，因为额外的上下文交换导致操作系统将 CPU 周期花在维护线程而不是处理请求上。
使用 HttpServerUtility.Transfer 方法在同一应用程序的页面间重定向。采用 Server.Transfer 语法，在页面中使用该方法可避免不必要的客户端重定向。
使请求管线内的所有模块尽可能高效。请求管线内的所有模块在每次请求中都有机会被运行。因此，当请求进入和离开模块时快速地触发代码至关重要，特别是在不使用模块功能的代码路径里。分别在使用及不使用模块和配置文件时执行吞吐量测试，对确定这些方法的执行速度非常有用。
在 Visual Basic .NET 或 JScript 代码中使用早期绑定。以往，开发人员喜欢使用 Visual Basic、VBScript 和 JScript 的原因之一就是它们所谓“无类型”的性质。变量不需要显式类型声明，并能够简单地通过使用来创建它们。当从一个类型到另一个类型进行分配时，转换将自动执行。不过，这种便利会大大损害应用程序的性能。
Visual Basic 现在通过使用 Option Strict 编译器指令来支持类型安全编程。为了向后兼容，默认情况下，ASP.NET 不启用该选项。但是，为了得到最佳性能，强烈建议在页中启用该选项。若要启用 Option Strict，请将 Strict 属性包括在 @ Page 指令中，或者，对于用户控件，请将该属性包括在 @ Control 指令中。下面的示例演示了如何设置该属性，并进行了四个变量调用以显示使用该属性是如何导致编译器错误的。
<%
Dim B
Dim C As String' This will cause a compiler error.
A = "Hello"
' This will cause a compiler error.
B = "World"
' This will not cause a compiler error.
C = "!!!!!!"
' But this will cause a compiler error.
C = 0
%>JScript .NET 也支持无类型编程，但它不提供强制早期绑定的编译器指令。若发生下面任何一种情况，则变量是晚期绑定的： 被显式声明为 Object。
是无类型声明的类的字段。
是无显式类型声明的专用函数或方法成员，并且无法从其使用推断出类型。
最后一个差别比较复杂，因为如果 JScript .NET 编译器可以根据变量的使用情况推断出类型，它就会进行优化。在下面的示例中，变量 A 是早期绑定的，但变量 B 是晚期绑定的。 var A;
var B;A = "Hello";
B = "World";
B = 0;为了获得最佳的性能，当声明 JScript .NET 变量时，请为其分配一个类型。例如，var A : String。 将调用密集型的 COM 组件迁移到托管代码。.NET Framework 提供了一个简单的方法与传统的 COM 组件进行交互。其优点是可以在保留现有投资的同时利用新的平台。但是在某些情况下，保留旧组件的性能开销使得将组件迁移到托管代码是值得的。每一情况都是不一样的，决定是否需要迁移组件的最好方法是对 Web 站点运行性能测量。建议您研究一下如何将需要大量调用以进行交互的任何 COM 组件迁移到托管代码。
许多情况下不可能将旧式组件迁移到托管代码，特别是在最初迁移 Web 应用程序时。在这种情况下，最大的性能障碍之一是将数据从非托管环境封送到托管环境。因此，在交互操作中，请在任何一端执行尽可能多的任务，然后进行一个大调用而不是一系列小调用。例如，公共语言运行库中的所有字符串都是 Unicode 的，所以应在调用托管代码之前将组件中的所有字符串转换成 Unicode 格式。 另外，一处理完任何 COM 对象或本机资源就释放它们。这样，其他请求就能够使用它们，并且最大限度地减少了因稍后请求垃圾回收器释放它们所引起的性能问题。 避免单线程单元 (STA) COM 组件。默认情况下，ASP.NET 不允许任何 STA COM 组件在页面内运行。若要运行它们，必须在 .aspx 文件内将 ASPCompat=true 属性包含在 @ Page 指令中。这样就将执行用的线程池切换到 STA 线程池，而且使 HttpContext 和其他内置对象可用于 COM 对象。前者也是一种性能优化，因为它避免了将多线程单元 (MTA) 封送到 STA 线程的任何调用。
使用 STA COM 组件可能大大损害性能，应尽量避免。若必须使用 STA COM 组件，如在任何 interop 方案中，则应在执行期间进行大量调用并在每次调用期间发送尽可能多的信息。另外，小心不要在构造页面期间创建任何 STA COM 组件。例如下面的代码中，在页面构造时将实例化由某个线程创建的 MySTAComponent，而该线程并不是将运行页面的 STA 线程。这可能对性能有不利影响，因为要构造页面就必须完成 MTA 和 STA 线程之间的封送处理。 <%@ Page Language="VB" ASPCompat="true" %>
<script runat=server>
Dim myComp as new MySTAComponent()
Public Sub Page_Load()
myComp.Name = "Bob"
End Sub
</script>
<html>
<%
Response.Write(myComp.SayHello)
%>
</html>首选机制是推迟对象的创建，直到以后在 STA 线程下执行上述代码，如下面的例子所示。 <%@ Page Language="VB" ASPCompat="true" %>
<script runat=server>
Dim myComp
Public Sub Page_Load()
myComp = new MySTAComponent()
myComp.Name = "Bob"
End Sub
</script>
<html>
<%
Response.Write(myComp.SayHello)
%>
</html>推荐的做法是在需要时或者在 Page_Load 方法中构造任何 COM 组件和外部资源。 永远不要将任何 STA COM 组件存储在可以由构造它的线程以外的其他线程访问的共享资源里。这类资源包括像缓存和会话状态这样的资源。即使 STA 线程调用 STA COM 组件，也只有构造此 STA COM 组件的线程能够实际为该调用服务，而这要求封送处理对创建者线程的调用。此封送处理可能产生重大的性能损失和可伸缩性问题。在这种情况下，请研究一下使 COM 组件成为 MTA COM 组件的可能性，或者更好的办法是迁移代码以使对象成为托管对象。
<system.web>
<pages enableViewState="false" />
</system.web>
</configuration>
其它如楼上