1. Exception handling block should be less and we have to handle most of the exceptions manually. Don’t put your entire code in an exception handling block. Keep code where un-handle exception can raise, like data base connections.
2. Don’t write exception handle block in loops, it cost more.
3. Make sure that resources are closed after use by using try/catch blocks. The finally block is always executed, even if an exception occurs.
1. Set session state to read only in each page if we are not writing to any session variables.
2. Avoid storing STA COM objects in session state
3. Store simple state on the client where possible.
1. Try to keep the page size to a minimum. Large page sizes place increased load on the CPU because of increased processing and a significant increase in network bandwidth utilization, which may lead to network congestion. Both of these factors lead to increased response times for clients. Consider the following guidelines to help reduce page size:
i. Remove redundant white space characters from your HTML.
ii. Disable view state for server controls where it is not needed.
iii. Avoid long control names.
iv. Minimize the use of graphics, and use compressed images.
v. Consider using cascading style sheets to avoid sending the same formatting directives to the client repeatedly.
2. Evaluate each page to determine if you need view state enabled. View state adds overhead to each request. The overhead includes increased page sizes sent to the client as well as a serialization and deserialization cost. You do not need view state under the following conditions:
i. The page does not post back to itself; the page is only used for output and does not rely on response processing.
ii. Your page’s server controls do not handle events and you have no dynamic or data-bound property values (or they are set in code on every request).
iii. If you are ignoring old data and repopulating the server control every time the page is refreshed.
3. Evaluate your use of server controls to determine if you can replace them with lightweight HTML controls or possibly static text. You might be able to replace a server control under the following conditions:
i. The data being displayed in the control is static, for example, a label.
ii. You do not need programmatic access to the control on the server side.
iii. The control is displaying read-only data.
iv. The control is not needed during post back processing.
1. Review your code and ensure that Explicit option is turned on. This ensures that all narrowing type coercions must be explicitly specified. This protects you from inadvertent late binding and enforces a higher level of coding discipline. Option Explicit forces you to declare a variable before using it by moving the type inference from run time to compile time.
2. Ensure that you have buffering enabled. Buffering causes the server to buffer the output and send it only after it has finished the processing of the page. If buffering is disabled, the worker process needs to continuously stream responses from all concurrent requests; this can be a significant overhead on memory and the processor, especially when you use the ASP.NET process model. To find out if you have buffering disabled, you can search your code base for the following strings: “buffer” and “BufferOutput.” Make sure that the buffer attribute is set to true on the <pages> element in your application’s Web.config file.
3. Check that the logic in your page uses the Page.IsPostBack property to reduce redundant processing and avoid unnecessary initialization costs. Use the Page.IsPostBack property to conditionally execute code, depending on whether the page is generated in response to a server control event or whether it is loaded for the first time.
4. Avoid calling Page.DataBind and bind each control individually to optimize your data binding. Calling Page.DataBind recursively calls DataBind on each control on the page String Operations
i. If you know the number of appends to be made and you are concatenating the strings in one shot, prefer the & operator for concatenation.
ii. Use StringBuilder when the number of appends is unknown
iii. Check whether your code performs case-insensitive string comparisons. If it does, check that it uses the following overloaded Compare method.
1. Identify places in your code where you use object arrays (arrays containing theObject type). If you use object arrays to store other types, such as integers or floats, the values are boxed when you add them to the array. Use a strongly typed array instead, to avoid the boxing.
2. Arrays avoid boxing and unboxing overhead for value types, as long as you use strongly typed arrays. You should consider using arrays for collections where possible unless you need special features such as sorting or storing the values as key/value pairs.
3. When dealing with very large numbers of objects, it becomes very important to manage the size of each object. For example, it makes little difference whether you use a short (Int16), int/Integer (Int32), or long (Int64) for a single variable, but it can make a huge difference if you have a million of them in a collection or array.
1. It is more efficient to initialize collections to a final approximate size even if the collection is capable of growing dynamically. For example, you can initialize an ArrayList using the following overloaded constructor.
2. Does your code use an ArrayList for storing string types? You should prefer StringCollection over ArrayList when storing strings. This avoids casting overhead that occurs when you insert or retrieve items and also ensures that type checking occurs.
3. Store presorted data and use ArrayList.BinarySearch for efficient searches. Sorting and linear searches using Contains are inefficient. This is of particular significance for large lists. If you only have a few items in the list, the overhead is insignificant. If you need several lookups, then consider Hashtable instead of ArrayList.
4. Store presorted data and use ArrayList.BinarySearch for efficient searches. Sorting and linear searches using Contains are inefficient. This is of particular significance for large lists. If you only have a few items in the list, the overhead is insignificant. If you need several lookups, then consider Hashtable instead of ArrayList.
1. Use Database specific data provider. i.e. For oracle, use System.Data.OracleClient rather than using System.Data.Oledb provider.
2. Explicitly Close connections by calling either Close or Dispose methods.
3. Avoid checking the Connection state property. Instead of handle StateChange event to track the connection status.
4. Do not vary connection strings. Different connection strings generate different Connection pools. For example, using different capitalization, extra spaces, or Different ordering of attributes causes connections to go to different pools.
5. Retrieve only the columns and rows you need.
6. Batch SQL statements to reduce round trips.
7. Use ExecuteNonQuery for commands that do not return data.
8. Use ExecuteScalar to return single values.
9. Check that your code calls Dispose or Close on all classes that support these methods. Common disposable resources include the following:
i. Database-related classes: Connection, DataReader, and Transaction.
ii. File-based classes: FileStream and BinaryWriter.
iii. Stream-based classes: StreamReader, TextReader, TextWriter, BinaryReader and TextWriter.
1. If you create and destroy COM objects on a per-request basis under load, consider calling ReleaseComObject.
2. Consider calling Marshal.ReleaseComObject in a finally block to ensure that COM objects referenced through a runtime callable wrapper (RCW) release properly even if an exception occurs.When you reference a COM object from ASP.NET, you actually maintain a reference to an RCW. It is not enough to simply assign a value of null to the reference that holds the RCW, and instead you should call Marshal.ReleaseComObject. This is of most relevance to server applications because under heavy load scenarios, garbage collection (and finalization) might not occur soon enough and performance might suffer due to a build up of objects awaiting collection. A common pitfall when releasing COM objects is to set the object to null and call GC.Collect followed by GC.WaitForPendingFinalizers. You should not do this because the finalization thread takes precedence over the application threads to run the garbage collection. This can significantly reduce application performance.
3. When you are trying to create a .NET dll component in a .NET dll using CREATEOBJECT, then use assembly loader. By using assembly loader we can create object similar to CREATEOBJECT but .NET JIT compiler will take care of object destruction and memory release.
1. Use XmlTextReader to process XML data quickly in a forward, read-only manner without using validation, XPath, and XSLT services.
2. Use XPathNavigator to obtain read-only, random access to XML data and to use XPath queries. To create an XPathNavigator object over an XML document, you must call the XPathDocument.CreateNavigator method
3. Use XmlTextWriter to write XML documents. You cannot use XmlTextWriter to update XML documents.
4. Use the XmlDocument class to update existing XML documents, or to perform XPath queries and updates in combination. To use XPath queries on the XmlDocument, use the Select method.
5. Try to keep the output document size to a minimum. If you are generating HTML, there are a couple of ways to do this. First, use cascading style sheets to apply formatting instead of embedding formatting metadata in the HTML. Second, consider how your HTML is indented, and avoid unnecessary white space. To do so, set the indent setting to no as shown in the following XSLT fragment.
1. Check your Web.config file and ensure debug is set to false in the <compilation> section and check your .aspx pages to ensure debug is set to false. If debugging is enabled, the compiler does not generate optimized code and pages are not batch compiled.
2. Including HttpModules that you do not need adds extra overhead to ASP.NET request processing. Check that you have removed or commented out unused HttpModules in Machine.config
1. Use Structures instead of Classes for limited functionality. Structures give better performance than classes in few scenarios. For each variable class do boxing and un-boxing which take system time and memory. When you are using objects in sessions then go for class and don’t use structures.