Tips and Tricks

Here's my first, and probably strongest, recommendation: Don't wait until the end of an application's development to test its performance. Of course, with a project manager breathing down your neck for completion of the various pieces, performance testing is the last thing on your mind. But you might not be able to make changes in the code if you're close to the end because of what else might break in the process.

If you performance test early in the game, code changes will have a minimal effect on other pieces of code. But after the codebase grows, more code depends on each different piece of code. It's best to performance test before code has too many dependencies.

Another suggestion is to use the ASP.NET trace feature for performance testing. You can use the trace output to figure out the amount of data that is round-tripped. For more about tracing, look at Chapter 22, "Debugging." This section discusses several different methods you can use to optimize the performance of your applications.

Binding

A frequent question that arises in almost every .NET seminar I go to is, "Which .NET language performs best?" The true answer is none ”they should all perform equally well. The one exception to this is if you use late binding in the languages (such as VB and JScript) that allow it.

VB and JScript support both early and late binding. Although late binding might have some advantages when it comes to convenience, it negates the gains that compilation makes because the types are not known until runtime.

The following example shows an early-bound DataSet declaration. When the ds variable is used, the compiler explicitly knows what it is and how to optimally access it.

 Dim ds as New DataSet 

A late-bound DataSet does not allow the compiler to optimize access to the object. The following example shows a late-bound DataSet :

 Dim ds  ' Do other stuff here  ds = New DataSet 

Viewstate Management

Viewstate is an incredibly useful item in ASP.NET applications. It enables application controls to maintain a persistent state between page requests . This means that a user can select from a list box, click on a response button of some sort , and then the list box state is preserved after the round trip to the server.

But if your application doesn't need viewstate, it adds extra payload size and requires extra server processing. When you don't require viewstate, you can turn it off in each page with the following directive:

 <%@ Page MaintainState="false" %> 

You also can turn off the viewstate for a single control. Turning viewstate off for selected controls reduces the payload size and processing load in a page, even if there is not viewstate material for all controls. The following datagrid will not maintain state:

 <asp:datagrid runat="server" maintainstate="false" /> 

Session State

As with viewstate, session state is another extremely useful tool. Developers need to persist some sort of session state in more than half of the ASP.NET applications. But this requires extra overhead for ASP.NET pages that support session state. For this reason, the mechanism to turn session state off for a page has been provided. If you turn it off, the page will perform better because it will require less processing time on the server end. The following page directive turns session state off:

 <%@ Page EnableSessionState="false" /> 

Database Access

You should make every effort to conserve database round trips. The best way to do this is by caching query results that don't change very often.

You also should use the SQL managed provider whenever possible because this will outperform the ODBC and OLE DB counterparts.

And of course, whenever possible, use stored procedures rather than ad hoc queries. This can really improve the performance of the database access, and thus the performance of your application.

SmartNavigation

Many ASP.NET pages perform a round trip to the server in response to a user interaction. This results in a page refresh that users notice. In some cases, depending on the connection bandwidth and computer speed, the refresh can detract from the user experience.

To minimize the round trip refresh problem, Microsoft has provided a SmartNavigation attribute that can be added to the page. With this attribute set to true, for later browsers (such as Internet Explorer 5.0 and later), the refresh is done in an IFRAME and will not be noticeable to the user. Although this is good with respect to the user experience, it does carry a price. The extra code needed to support the IFRAME increases the size of the payload, and thus slows the application down some.