Testing: GC Sanity Checks in Whidbey

I have a feeling this method will only be useful when you can run a series of tests without any collections taking place during your tests. Whenever a collection occurs you can never be sure of the amount of time spent in collection (anyone on the CLR want to surface that number without going to performance counters?) so you can't really get an understanding of how badly your test was affected. I've managed to run some rather long tests without any collections by pre-allocating everything to be used by the testing structure and avoiding additional allocations during the test process. Here is how I check for collections:

// Before my test
int[] collections = new int[3];
collections[0] = GC.CollectionCount( 0 );
collections[1] = GC.CollectionCount( 1 );
collections[2] = GC.CollectionCount( 2 );

// After my test
Console.WriteLine( "Collections: {0}, {1}, {2}",
    GC.CollectionCount( 0 ) - collections[0],
    GC.CollectionCount( 1 ) - collections[1],
    GC.CollectionCount( 2 ) - collections[2] );

What I've realized from this little method is that pre-allocating the testing structure really does make a huge difference. I can see 5 or 6 collections if my objects are allocated on the fly during the test and 0 collections if the are pre-allocated into an array or similar structure. Now, in many tests you aren't going to avoid allocating new objects during the test. In many cases the sole purpose of the test is to allocate new objects, such as return strings, or other data. If that is the case, you might want to look for a balance in the collection count between both of your testing methods, test multiple times, test for short periods and average over a large number of separate test loops, or use high performance counters to avoid the DateTime round-off issues.

Published Saturday, October 02, 2004 9:42 AM by Justin Rogers

Comments

No Comments

Leave a Comment

(required) 
(required) 
(optional)
(required)