Loops are excellent places to look for code that executes repeatedly for no good reason. Consider, for example, the following code, which reads through the results of a query. For each record, it searches the lastname field to determine whether it contains a string named lastname received from the Web visitor.

Do While rdrMembers.Read
  If InStr(UCase(rdrMembers.Item("lastname")), _
                 UCase(Request.Params("lastname"))) Then
    booFound = True
    Exit Do
  Else
    booFound = False
  End If
Loop

If booFound is True when the loop ends, the Exit Do statement must have executed and the record is positioned at the first matching record. If booFound is False, there was no matching record.

More important, however, is that the loop evaluates the expression UCase(Reques.Params("lastname")) and sets the value of the booFound variable once for each record the data reader returns. If there are 50 records, that’s 50 searches through the Request.Params collection, plus 50 conversions to uppercase, plus 50 variable assignments. The following code, which performs the same operations only once, is much more efficient:

strLastname = UCase(Request.Params("lastname"))
booFound = False
Do While rdrMembers.Read
  If InStr(UCase(rdrMembers.Item("lastname")), _
                 strLastname) Then
    booFound = True
    Exit Do
  End If
Loop

Retrieving values from collections of any type is relatively slow. If you need to access such a value more than once, store a copy in a local variable.

Concatenating strings is a relatively resource-intensive operation. When you concatenate a 20-byte string and a 30-byte string, for example, the run-time code must allocate a new 50-byte area, copy all 50 bytes into it, adjust a pointer so that it points to the new area, and then release the original data area.

The Response.Write method, by contrast, offers very efficient buffering and concatenation services. Therefore, if you need to write several consecutive strings into the Response stream, coding a Response.Write statement for each one is more efficient that coding one Response.Write statement for a concatenation. That is,

Response.Write("Headline=")
Response.Write(strHeadline)
Response.Write(", Description=")
Response.Write(rdrAds.Item("Description"))

is more efficient than

Response.Write("Headline=") & _
               strHeadline & _
               ", Description=" & _
               rdrAds.Item("Description"))

Although ASP.NET code can use traditional COM components, there are performance penalties in doing so. Each call to a COM component adds execution time and decreases throughput. The more calls your ASP.NET application makes to a given COM component, the greater the payback in converting that object to a new or existing .NET class. Alternatively, if the COM component is something you or your organization developed, you might consider redesigning it to require fewer calls or to pass more data during a single call.

Visual Basic .NET has a ReDim statement that can change the size of an array. This command creates a new array of the requested size, optionally copies all the data from the old array, and then deletes the old array and replaces its address with that of the new one. This process makes redimensioning an array fairly time-consuming.

Never write loops that redimension an array once for each additional item. It’s much better to make the array fairly large to begin with and redimension it only in exceptional cases. If using a few extra kilobytes of memory presents a problem, it’s time to upgrade your hardware anyway.

Also, keep the ArrayList and Hashtable objects in mind. These objects are normally less efficient than an ordinary array, but more efficient than using an ordinary array poorly.

Exception handling is an extremely time-consuming process. Therefore, you shouldn’t use a Try...Catch...End Try block to detect conditions that you could detect with normal code. Here are some examples:

The following code, for example, is very inefficient:

Try
  lngQuotient = 100 / lngDivisor
Catch (e As Exception)
  lngQuotient = 0
End Try

The next block of code is much more efficient and produces the same result:

If lngDivisor = 0 Then
  lngQuotient = 0
Else
  lngQuotient = 100 / lngDivisor
End If

For years, Visual Basic, VBScript, and JScript programmers have used a feature called automatic type conversion. Under this concept, if a receiving variable wasn’t the correct type at run time, the language converted it. If the receiving variable didn’t exist, the language created it.

Visual Basic .NET calls this feature late binding and officially discourages it. Compared to early binding, where the compiler knows the one and only data type each variable will have, late binding is considerably less efficient.

There are two distinct ways to save yourself from the evils of late binding. The first is to make a habit of always declaring variables with fixed data types. In other words, don’t declare variables As Object or with no As clause at all.

The second way to prevent late binding is to code Option="Strict" in the @ Page directive for a Web page or the @ Control directive for a user control. This option will also prevent data conversions that might lose data, such as assigning a Long value to an Integer variable.

Always disable debug mode and trace mode before deploying a production application or conducting any performance measurements. If you leave these modes enabled, performance can suffer a great deal.

If you have Web pages that run frequently and use resource-intensive methods to obtain relatively static data, you can probably improve performance by retrieving that data just once and storing it in the Application object.

You can store almost anything you like in the Application object: simple variables, application parameters, arrays, and objects—to name just a few things. Remember, though, that everything in the Application object remains constantly in memory. Putting a few kilobytes of information into the Application object shouldn’t present a problem, but storing information by the megabyte is a bad idea.

When handling a Web form, the code that handles initial form display is usually quite different from the code that handles a submission (that is, a postback). During initialization, there’s no point in trying to process form data because at this point, the visitor hasn’t submitted any. There’s usually no reason to run the initialization code when an actual form submission (that is, a postback) occurs. The ViewState mechanism will preserve any form elements you initialize.

The Page.IsPostBack property makes it quite easy to differentiate these two cases. Here’s an example:

Sub Page_Load(sender As Object, e As EventArgs)
  If Page.IsPostBack
'  Code to process form submission goes here.
Else
'  Code to initialize form goes here.
  End If
End Sub

Each tag you code with the runat="server" attribute creates extra work for the Web server. Therefore, don’t code tags with this attribute unless you need to manipulate the control’s properties, handle the control’s events on the server, or take advantage of ViewState preservation. In many cases, a simple code render block or data-binding expression will serve the same purpose as a server control but use fewer resources.

ASP.NET ViewState management saves the properties of server controls from one page execution to the next. ASP.NET does this by encoding the property values in a hidden form field that it adds to each outgoing response. When the visitor submits another request, ASP.NET decodes the hidden form field and restores the server control properties. By default, this process occurs for every server control on an ASP.NET page.

Of course, the more server controls you include in the ViewState and the more data they contain, the greater the load on the Web server. And, just to make life worse, ViewState preservation can sometimes be a nuisance. In the case of a Literal control that displays an error message, for example, you’d most likely prefer that ASP.NET not keep repeating it on every page (unless, of course, you remember to clear the message in code).

To disable the ViewState for a particular control, set its EnableViewState property to False, as in the following example:

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

To disable the ViewState for an entire page or user control, set the EnableViewState property in the @ Page or @ Control directive. Here are some examples:

<%@ Page EnableViewState="false" %>
<%@ Control EnableViewState="false" %>

The standard trace display reports the amount of ViewState space each server control uses. To get this information, first enable tracing (by including a trace="true" attribute in the @ Page directive), run the page, and then look at the Viewstate column of the Control Hierarchy table.

Not all applications or pages require the use of the Session object. On those that don’t, you might as well disable it. To disable the session state for a page, set the EnableSessionState attribute in the @ Page directive to False. For example,

<%@ Page EnableSessionState="false" %>

If a page requires access to session variables, but won’t create or modify them, set the EnableSessionState attribute in the @ Page directive to ReadOnly. To disable the session state for an entire application, open the application’s web.config file and then, in the sessionstate configuration section, set the mode attribute to off. Here’s an example:

<sessionstate mode="off" />

ASP.NET provides three distinct ways to store session data for your application:

Each approach has its advantages, but in-process session state is by far the fastest solution. If you’re storing only small amounts of volatile data in session state, use the in-process provider.

The two out-of-process solutions are useful primarily if you scale your application across multiple servers, or if you must preserve session data even though you restart a server or process.

In cases where an ASP.NET page doesn’t need to generate fresh page output or data for every page request, caching can offer tremendous performance improvements. ASP.NET can even cache different versions of page output based on different incoming form field values. For more information about output caching, refer to "Coding the @ OutputCache Directive" in Chapter 3.

ASP.NET makes it easy for code on the Web server to respond to events on the browser. However, round trips are a trick best used sparingly. In general, you should initiate round trips only when your application needs to store or retrieve data. Interactive data display and data manipulation occur more smoothly and more efficiently on the browser.

Input validation is an excellent function to run on the browser. The Web visitor gets a faster response and the Web server gets fewer hits. Keep in mind, however, that some very old browsers don’t support browser-side scripting, and some current browsers let Web visitors turn it off. Don’t reduce server-side validation so much that outdated browsers or mischievous visitors can compromise your system.

If you followed the recommendations under "Designing a Database" in Chapter 6, your database should have a sound fundamental design. If you didn’t and now you have a mess, consider redesigning the database with all-new table names and then creating stored queries that mimic the tables in the original database. This will keep your existing Web site running while you revise the high-hitting, long-running Web pages to use the new structure. Here are some additional tips to keep in mind:

Poorly constructed queries are among the most common causes of poor database performance. Here are some tips for getting the same results in significantly less time:

Of all the data access methods the .NET Framework provides, Microsoft highly recommends SQL Server for building high-performance, scalable Web applications. The .NET classes that access SQL Server use SQL Server’s native network data-transfer format to read data directly from a database connection, making it faster than the multi-layered architecture of OLE DB.

The DataReader classes retrieve a forward-only stream of data from a database, which is less functional but also more efficient than using a DataSet class. If a data reader meets your requirements, a data reader should be your solution of choice.

Don’t forget that data readers also implement the IEnumerable interface. You can bind data readers to Web server controls like the DataGrid and the DropDownList.

Stored procedures are blocks of script code that reside on the database server. Microsoft SQL Server, for example, supports stored procedures written in a language called Transact-SQL. Because stored procedures run in an environment closely bound to the database server, they’re frequently the most efficient way to complete a series of database operations that depend on each other. When you want to execute a stored query, you just send the database system its name and any replaceable parameters. The topic "Using Stored Procedures" in Chapter 7 explained how to run a stored query.

Query optimization is one of the first steps required to process any SQL statement. During this step, the database system analyzes the submitted SQL, analyzes the structure of the database, and develops (with any luck) an optimal strategy for efficiently retrieving the requested data. Most databases perform this step when you save a stored query—not when an application runs it. With a conventional query, of course, the database system must optimize the query at run time. For this reason, running a stored query is often faster than running the same query supplied as text.

Although Microsoft Access, SQL Server, and most other databases can store binary objects such as pictures and sounds, it’s best to avoid this practice for Web database pages. For one thing, these objects make the database physically larger and thus increase search times. More importantly, though, retrieving data stored this way requires querying the database an additional time for each object you use on the same Web page.

To understand this problem, consider that an ASP.NET page can’t send the browser an image or a sound file along with the HTML. It can only send an <img> tag that gives that file’s location. Thus, here’s how displaying a picture stored in a database has to work:

It should be obvious at this point that running another ASP.NET page, executing another query, and copying the data out of the database and into the Response object requires much more processing than delivering a simple .wav, .gif, or .jpg file. The best approach, therefore, is to store the picture, sound, or other binary file as a normal file on the Web server and record only its name in the database.

In the context of databases, an index is a table of values that exist within another table. However, the sequence of records in an index is different from the sequence of records in the original table. To see how this works, imagine that your database has an employee table with the employee number field as its primary key.

When you ask the database system to process a SQL statement, the query optimizer takes note of any applicable indexes and uses them to speed up processing. If the query asks for a specific primary key, for example, the optimizer will no doubt decide to search for it using the primary key index. Most database systems can support multiple indexes per table.

If you queried the same table for all employee surnames beginning with the letter B, the database system would have to read through every record in the employee table looking for surnames that begin with that letter. If you asked for these records in surname sequence, the database system would construct a temporary index of the found records and use it to retrieve the matching records in the requested order. Creating a temporary index involves much more work than using an existing index to do the same thing.

Although indexes speed lookup and often eliminate the need for sorting, they aren’t free. For one thing, indexes consume additional disk space. For another, whenever an application adds, modifies, or deletes a record in an indexed table, the database system also needs to update all the indexes. This process can be a significant performance hit.

In general, indexing a given field will be more attractive to the extent that the following conditions are true:

However, there’s no hard-and-fast rule: you should be willing to create or delete indexes and then monitor the resulting performance.