Here are some rules that should be followed for writing high performing applications.

Use Caching to Store Your Content

As you know, ASP.NET allows you to cache entire pages, fragments of pages, or controls. You also can cache variable data by specifying the parameters on which the data depends. By using caching, you help the ASP.NET engine to return data for repeated requests for the same page much faster. There is one catch here: Caching consumes server memory, so it's not recommended to be used when you need to get updated data on your page.

Avoid Session State

Whether you store your data in in-process, on a state server, or in a SQL database, session state requires memory; it's also time consuming when you store or retrieve data from it. If you do not want to use session state, disable it on your web form by using the <@%Page EnableSessionState="falseb"%> directive. In case you use the session state only to retrieve data from it and not to update it, make the session state read only by using the <@%Page EnableSessionState ="ReadOnly"%> directive.

Avoid ViewSate

ViewState allows you to keep the content of a control across trips to the server. This comes with a cost: A greater amount of data is sent from the server to client end vice versa, so the speed and network bandwidth can be affected. You can avoid this drawback by setting the EnableViewState property of your web controls to false when you don't need them to keep their state across server trips.

Use Low-Cost Authentication

Authentication also can have an impact over the performance of your application. For example, passport authentication is slower than form-base authentication, which in turn is slower than Windows authentication.

Use the Server.Transfer() Method for Server-Side Page Redirection

It is better to use the Server.Transfer() method for server-side ASPX page redirection in the same application than the Response.Redirect() method. This will reduce the extra roundtrip required by the second method (Response.Redirect()) to perform client-side redirection.

Reduce The Number of Web Server Controls

The use of web server controls increases your application's response time because they need time to be processed on the server side before they are rendered on the client side. Therefore, take in consideration the usage of HTML elements where they are suited; for example, if you want to display static text.

Avoid Frequent Usage of Boxing and Unboxing

When a value type, such as a structure, is copied to a reference type such as a class, the compiler creates an object on the heap and copies the value of the value type from the stack to this newly created object on the heap. This process is called boxing and requires more overhead than just a simple from value type to value type. When you copy a reference type to a value type, the value of the object from the heap is copied to the value type from the stack. This process is called unboxing. You should take in consideration the overhead of these processes when you design your application.

Avoid Using the String Type for Complex Strings Operations

The string type is immutable; this means that after a string is created it can't be modified. When you modify a string, the CRL creates a new string based on your modifications and returns it. The old string remains in memory until garbage collector clears it. If your application is extensively modifying strings, use the StringBuilder class. This class stores the string as an array of characters. The StringBuilder object is mutable and does in-place modifications of strings.

Use the AddRange() Method with Collections

There is a large number of collection classes that expose the AddRange() method. You can use this to add an array of items to the collection instead of calling the Add() method repeatedly inside a loop.

Avoid Throwing Exceptions

Throwing exceptions is a costly operation. You should be very careful when you throw an exception from your application. Exceptions should be thrown only to signify exceptional error cases. You should never throw exceptions just to manage your application flow.

Avoid Using Unmanaged Code

Calls to unmanaged code are a costly marshaling operation. Try to reduce the number of calls between the managed and unmanaged code. Consider doing more work in each call rather than making frequent calls to do small tasks.

Avoid Making Frequent Calls Across Processes

If you are working with distributed applications, this involves additional overhead negotiating network and application level protocols. In this case, network speed can also be a bottleneck. Try to do as much work as possible in fewer calls over the network.

Make Use of Optimized Managed Providers

As you know, OleDb is a generic provider that offers access to data exposed by any OleDb provider. Managed providers are specifically optimized for some databases. For example, when you use OleDb to connect to a SQL server database, OleDb first passes your request to the OLE DB COM components, which in turn translate the request to SQL Native Tabular Data Stream (TDS) format. Using SqlClient directly constructs the TDS packets and communicates with SQL server. The removal of the extra translation will significantly improve your application's performance.

Use Stored Procedures and Not SQL Statements

When you are working with a RDBMS as a SQL server, you should use stored procedures rather than SQL statements given as a text command because stored procedures are highly optimized for server-side data access.

Use DataReader Instead of DataSet for Forward-Only Sequential Access

If you are reading a table sequentially, you should use the DataReader rather than DataSet. The DataReader object creates a read-only stream of data that will increase your application performance because only one row is in memory at a time.

Use Connection Pooling

The slowest operation performed in a database application scenario is establishing a connection with a database. The SQL server .NET Data Provider offers connection pooling to improve performance when connecting to a SQL server database. In connection pooling, old connection information is stored in a connection pool so it can be re-used for the next connection. If you are using dynamic connection strings, you should disallow the connection pooling mechanism because connections are only pooled on the exact connection string.

Use Transactions

Distributed transactions might add performance overhead to your application, so you should use them only when required and keep their life as short as possible.

About the Author
I work as a software developer for about 3 years. Until these days I have worked for different international software companies using different technologies and programming languages like: C/C++, lotus script, lotus API, C#, ASP.NET, MS-SQL, Oracle, Domino Server. My main interest, at this time, is focused on .NET technology (http://dotnetcaffe.net).

Tools:

Add www.codeguru.com to your favorites Add www.codeguru.com to your browser search box IE 7 | Firefox 2.0 | Firefox 1.5.x Receive news via our XML/RSS feed