DevPartner – how to avoid slow code under the .NET framework

Slow code – what are the causes and what can you do about them?

Welcome to this short series of blog articles where we provide a practical guide to identifying and addressing some of the core issues around slow code.  We kick the series off by looking ay the importance of selecting Programming Constructs wisely. Future blogs will consider factors like Application Memory and Database Calls. Please feel free to comment and share your experiences with us.

The importance of selecting Programming Constructs wisely

Programming for performance in managed code under the .NET Framework is geared towards optimizing those operations that carry a heavy computing cost, such as database calls, memory allocations (especially large ones), floating point operations and certain Framework calls. 

.NET performance analysis helps determine which calls are more expensive than others.

Most or all of these expensive operations will have to be executed at some point, the trick is to do them as seldom as possible, in more efficient ways. This is where combining performance analysis with code reviews pays off as, armed with performance information, code reviews can focus on refactoring to achieve better code execution times.

A development team may well focus on the time taken to execute code, but equal attention needs to be paid to the frequency of executing a particular piece of code. A single call might be relatively inexpensive but placing that call in a loop could involve executing an expensive operation thousands of times.

That, in fact, represents a significant difference between managed and native code.  Memory allocations are inexpensive in native code, and releases are comparatively expensive.  In managed code, the opposite is true – allocations are expensive, and releases are inexpensive.

The .NET Framework provides alternative means of performing many actions.  When there are several choices available, developers should choose the calls that perform the actions they require, without a lot of additional computation.  Developers should analyze the performance of alternative Framework calls to identify the best calls for their purposes.

Full performance analysis, such as that available within DevPartner, traces the time it takes to execute every line of code, and every operation, as well as how many times that line is executed.  This gives insight and provides the ability to fully understand how fast it takes to execute code, down to each individual line.

In the next article we examine how to identify poor memory usage within applications.

Share this post:

Leave a Reply

Your email address will not be published. Required fields are marked *