Gallery

Why collect garbage?

Posted on 23 May 2006 at 11:27

Thomas Lee demonstrates how the .NET framework is responsible for reclaiming your system's vital resources

Profiling your application

For the IT professional, the garbage collection process is just another interesting aspect of .NET that's not hugely relevant to everyday work. On the other hand, developers need to be aware of how .NET manages memory so they can write code that isn't hostile to it, thus it matters a great deal. However, before you can do anything to correct an application that's garbage collection-hostile, you first need to be able to work out that garbage collection is in fact the problem. You can do this by using the .NET Profiler and Performance Monitor. To illustrate the garbage collection process, I'm going to use two small C# programs called S1 and S1b. Here's S1.CS (the C# source):

//S2.CS

using System;

public class S1

{

static void Main (string[] args)

{

int start = Environment.TickCount;

for (int i = 0; i < 1000; i++)

{

string s="";

for (int j=0; j< 100; j++)

{

s += "Outer index = ";

s += i;

s += " Inner Index = ";

s +=j;

s += " ";

}

}

Console.WriteLine ("Program ran for {0} seconds", 0.001*(Environment.TickCount - start));

}

}

This program does some string handling, but in a way that's pretty .NET garbage collection-unfriendly. Whenever the program adds to the string using the += operator, .NET has to do some behind-the-scenes memory management, creating a new string in a managed heap large enough to hold the longer content, and marking the old string out-of-scope and thus ripe for garbage collection. Here's a more garbage collection-friendly version called S1B.CS:

//S1b.cs

using System;

using System;

using System.Text;

public class S1

{

static void Main (string[] args)

{

int start = Environment.TickCount;

for (int i = 0; i < 1000; i++)

{

StringBuilder s= new StringBuilder(2048);

for (int j=0; j< 100; j++)

{

s.Append("Outer index = ");

s.Append((string) i.ToString());

s.Append(" Inner Index = ");

s.Append((string) j.ToString());

s.Append(" ");

}

}

Console.WriteLine ("Program ran for {0} seconds", 0.001*(Environment.TickCount - start));

}

}

Program S1b employs the .NET StringBuilder class to extend the string in a garbage collection-friendly way. When I run these two programs on my home system, I get the following output:

[C:\gc]: ./s1.exe

Program ran for 3.047 seconds

[C:\gc]: ./s1b.exe

Program ran for 0.141 seconds

[C:\gc]:

The second version of the program runs over 20 times faster, mainly due to it spending far less time in garbage collection, as you can discover by using the Performance Monitor. The .NET CLR memory object allows you to watch a number of details about how the garbage collection is working, including the number of collections, time spent in garbage collection and more. These statistics can give you some goods clues about how a .NET application is using the managed heap. The screenshot above shows the Performance Monitor running a slightly modified version of both programs (I changed the loop bounds from i < 1000 to i < 1000 * 1000 in their 8th and 10th lines respectively to make them run a lot longer). As you'll see in the screenshot, S1Long (the longer-running version of S1) is spending significantly longer in garbage collection than S1Longb (the longer version of S1b). Note too that S1Long has performed a lot more Gen0 collections, and it's equally interesting that both Gen1 and Gen2 collections occur much less frequently than Gen0 collections.