- Item 11: Understand .NET Resource Management
- Item 12: Prefer Member Initializers to Assignment Statements
- Item 13: Use Proper Initialization for Static Class Members
- Item 14: Minimize Duplicate Initialization Logic
- Item 15: Avoid Creating Unnecessary Objects
- Item 16: Never Call Virtual Functions in Constructors
- Item 17: Implement the Standard Dispose Pattern
This chapter is from the book
This chapter is from the book
This chapter is from the book
Item 15: Avoid Creating Unnecessary Objects
The garbage collector does an excellent job of managing memory for you, and it removes unused objects in a very efficient manner. But no matter how you look at it, allocating and destroying a heap-based object takes more processor time than not allocating and not destroying a heap-based object. You can introduce serious performance drains on your program by creating an excessive number of reference objects that are local to your methods.
So don’t overwork the garbage collector. You can follow some simple techniques to minimize the amount of work that the GC needs to do on your program’s behalf. All reference types, even local variables, create memory allocations. These objects become garbage when no root is keeping them alive. For local variables, that is typically when the method in which they are declared is no longer active. One very common bad practice is to allocate GDI objects in a Windows paint handler:
protected override void OnPaint(PaintEventArgs e)
{
// Bad. Created the same font every paint event.
using (Font MyFont = new Font("Arial", 10.0f))
{
e.Graphics.DrawString(DateTime.Now.ToString(),
MyFont, Brushes.Black, new PointF(0, 0));
}
base.OnPaint(e);
}
OnPaint() gets called frequently. Every time it gets called, you create another Font object that contains the exact same settings. The garbage collector needs to clean those up for you. Among the conditions that the GC uses to determine when to run are the amount of memory allocated and the frequency of memory allocations. More allocations mean more pressure on the GC, causing it to run more often. That’s incredibly inefficient.
Instead, promote the Font object from a local variable to a member variable. Reuse the same font each time you paint the window:
private readonly Font myFont =
new Font("Arial", 10.0f);
protected override void OnPaint(PaintEventArgs e)
{
e.Graphics.DrawString(DateTime.Now.ToString(),
myFont, Brushes.Black, new PointF(0, 0));
base.OnPaint(e);
}
Your program no longer creates garbage with every paint event. The garbage collector does less work. Your program runs just a little faster. When you elevate a local variable that implements IDisposable to a member variable, such as the font in this example, you need to implement IDisposable in your class. Item 17 explains how to properly do just that.
You should promote local variables to member variables when they are reference types (value types don’t matter) and they will be used in routines that are called frequently. The font in the paint routine is an excellent example. Only local variables in routines that are frequently accessed are good candidates. Infrequently called routines are not. You’re trying to avoid creating the same objects repeatedly, not turn every local variable into a member variable.
The static property Brushes.Black used earlier illustrates another technique that you should use to avoid repeatedly allocating similar objects. Create static member variables for commonly used instances of the reference types you need. Consider the black brush used earlier as an example. Every time you need to draw something in your window using the color black, you need a black brush. If you allocate a new one every time you draw anything, you create and destroy a huge number of black brushes during the course of a program. The first approach of creating a black brush as a member of each of your types helps, but it doesn’t go far enough. Programs might create dozens of windows and controls and would create dozens of black brushes. The .NET Framework designers anticipated this and created a single black brush for you to reuse whenever you need it. The Brushes class contains a number of static Brush objects, each with a different common color. Internally, the Brushes class uses a lazy evaluation algorithm to create only those brushes you request. A simplified implementation looks like this:
private static Brush blackBrush;
public static Brush Black
{
get
{
if (blackBrush == null)
blackBrush = new SolidBrush(Color.Black);
return blackBrush;
}
}
The first time you request a black brush, the Brushes class creates it. The Brushes class keeps a reference to the single black brush and returns that same handle whenever you request it again. The end result is that you create one black brush and reuse it forever. Furthermore, if your application does not need a particular resource—say, the lime green brush—it never gets created. The framework provides a way to limit the objects created to the minimum set you need to accomplish your goals. Consider that technique in your programs. On the positive side, you create fewer objects. On the minus side, this may cause objects to be in memory for longer than necessary. It can even mean not being able to dispose of unmanaged resources because you can’t know when to call the Dispose() method.
You’ve learned two techniques to minimize the number of allocations your program performs as it goes about its business. You can promote often-used local variables to member variables. You can use dependency injection to create and reuse objects that represent common instances of a given type. The last technique involves building the final value for immutable types. The System.String class is immutable: After you construct a string, the contents of that string cannot be modified. Whenever you write code that appears to modify the contents of a string, you are actually creating a new string object and leaving the old string object as garbage. This seemingly innocent practice:
string msg = "Hello, "; msg += thisUser.Name; msg += ". Today is "; msg += System.DateTime.Now.ToString();
is just as inefficient as if you had written this:
string msg = "Hello, "; // Not legal, for illustration only: string tmp1 = new String(msg + thisUser.Name); msg = tmp1; // "Hello " is garbage. string tmp2 = new String(msg + ". Today is "); msg = tmp2; // "Hello <user>" is garbage. string tmp3 = new String(msg + DateTime.Now.ToString()); msg = tmp3; // "Hello <user>. Today is " is garbage.
The strings tmp1, tmp2, and tmp3 and the originally constructed msg ("Hello") are all garbage. The += operator on the string class creates a new string object and returns that string. It does not modify the existing string by concatenating the characters to the original storage. For simple constructs such as the previous one, you should use interpolated strings:
string msg = string.Format("Hello, {0}. Today is {1}",
thisUser.Name, DateTime.Now.ToString());
For more complicated string operations, you can use the StringBuilder class:
StringBuilder msg = new StringBuilder("Hello, ");
msg.Append(thisUser.Name);
msg.Append(". Today is ");
msg.Append(DateTime.Now.ToString());
string finalMsg = msg.ToString();
The example above is simple enough that you’d use string interpolation (see Item 4). Use StringBuilder when the logic needed to build the final string is too complex for string interpolation. StringBuilder is the mutable string class used to build an immutable string object. It provides facilities for mutable strings that let you create and modify text data before you construct an immutable string object. Use StringBuilder to create the final version of a string object. More importantly, learn from that design idiom. When your designs call for immutable types, consider creating builder objects to facilitate the multiphase construction of the final object. That provides a way for users of your class to construct an object in steps, yet maintain the immutability of your type.
The garbage collector does an efficient job of managing the memory that your application uses. But remember that creating and destroying heap objects still takes time. Avoid creating excessive objects; don’t create what you don’t need. Also avoid creating multiple objects of reference types in local functions. Instead, consider promoting local variables to member variables, or create static objects of the most common instances of your types. Finally, consider creating mutable builder classes for immutable types.