commonperformanceissuesinmanagedcode

Cancel Edit [WikiEntry.PreviewButtonText] Save
Return to HomePage



Code Review: Common Performance Issues in Managed Code 1.1


Source: http://msdn.microsoft.com/library/en-us/dnpag/html/ScaleNetChapt13.asp
J.D. Meier, Srinath Vasireddy, Ashish Babbar, Rico Mariani, and Alex Mackman


Common Performance Issues

During your code reviews, pay particular attention to the following areas:
* Frequent code paths. Prioritize your code review process by identifying code paths that are frequently executed and begin your review process in these areas.
* Frequent loops. Even the slightest inefficiency inside a loop is magnified many times over depending on the number of iterations. Specifically watch out for repetitive property access inside your loops, using foreach instead of for, performing expensive operations within your loops, and using recursion. Recursion incurs the overhead of having to repeatedly build new stack frames.

There are a few areas that regularly lead to performance bottlenecks. Start your code review by looking for the following common performance issues:
* Resource cleanup
* Exceptions
* String management
* Threading
* Boxing

Resource Cleanup
Failing to clean up resources is a common cause of performance and scalability bottlenecks. Review your code to make sure all resources are closed and released as soon as possible. This is particularly important for shared and limited resources such as connections. Make sure your code calls Dispose (or Close) on disposable resources. Make sure your code uses finally blocks or using statements to ensure resources are closed even in the event of an exception.
Exceptions
While structured exception handling is encouraged because it leads to more robust code, and code that is less complex to maintain than code that uses method return codes to handle error conditions, exceptions can be expensive.
Make sure you do not use exception handling to control regular application flow. Use it only for exceptional conditions. Avoid exception handling inside loops — surround the loop with a try/catch block instead if that is required. Also identify code that swallows exceptions or inefficient code that catches, wraps, and rethrows exceptions for no valid reason.
String Management
Excessive string concatenation results in many unnecessary allocations, creating extra work for the garbage collector. Use StringBuilder for complex string manipulations and when you need to concatenate strings multiple times. If you know the number of appends and concatenate strings in a single statement or operation, prefer the + operator. In ASP.NET applications, consider emitting HTML output by using multiple Response.Write calls instead of using a StringBuilder.
Threading
Server-side code should generally use the common language runtime (CLR) thread pool and should not create threads on a per-request basis. Review your code to ensure that appropriate use is made of the thread pool and that the appropriate synchronization primitives are used. Make sure your code does not lock whole classes or whole methods when locking a few lines of code might be appropriate. Also make sure your code does not terminate or pause threads, by using Thread.Abort or Thread.Suspend.
Boxing
Boxing causes a heap allocation and a memory copy operation. Review your code to identify areas where implicit boxing occurs. Pay particular attention to code inside loops where the boxing overhead quickly adds up. Avoid passing value types in method parameters that expect a reference type. Sometimes this is unavoidable. In this case, to reduce the boxing overhead, box your variable once and keep an object reference to the boxed copy as long as needed, and then unbox it when you need a value type again.
Excessive boxing often occurs where you use collections that store System.Object types. Consider using an array or a custom-typed collection class instead.
To identify locations that might have boxing overhead, you can search your assembly's Microsoft intermediate language (MSIL) code for the box and unbox instructions, using the following command line.

Ildasm.exe yourcomponent.dll /text | findstr box
Ildasm.exe yourcomponent.dll /text | findstr unbox

To measure the overhead, use a profiler.
Summary
Performance and scalability code reviews are similar to regular code reviews or inspections, except that the focus is on the identification of coding flaws that can lead to reduced performance and scalability.
This chapter has shown how to review managed code for top performance and scalability issues. It has also shown you how to identify other more subtle flaws that can lead to performance and scalability issues.
Performance and scalability code reviews are not a panacea. However, they can be very effective and should be a regular milestone in the development life cycle.
Additional Resource
For more information, see the following resources:
* Chapter 4 "Architecture and Design Review of a .NET Application for Performance and Scalability."
* Chapter 6, "Improving ASP.NET Performance."
* Chapter 7, "Improving Interop Performance."
* Chapter 8, "Improving Enterprise Services Performance."
* Chapter 9, "Improving XML Performance."
* Chapter 10, "Improving Web Services Performance."
* Chapter 11, "Improving Remoting Performance."
* Chapter 12, "Improving ADO.NET Performance."
For printable checklists, see the following checklists in the "Checklists” section of this guide:
* "Checklist: ASP.NET Performance."
* "Checklist: Managed Code Performance."
* "Checklist: Enterprise Services Performance."
* "Checklist: Interop Performance."
* "Checklist: Remoting Performance."
* "Checklist: Web Services Performance."
* "Checklist: XML Performance."
For further reading, see the following resource:
* For more information about designing for performance, see "Performance" on MSDN at http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vsent7/html/vxconPerformance.asp?frame=true.



Return to HomePage
Microsoft Communities