16

I'm running some benchmark tests over my code and I want to make sure a garbage collect doesn't occur during one of my benchmarks because it's cleaning up the mess of a prior test. I figure my best chance of this is to force a collect before starting a benchmark.

So I'm calling GC.Collect() before a benchmark starts but not sure if a collect continues to run in a separate thread, etc and returns immediately. If it does run on a BG thread I want to know how to call it synchronously or a at least wait til it's finished the collect.

CodeAndCats
  • 7,508
  • 9
  • 42
  • 60
  • 1
    possible duplicate of [Run GC.Collect synchronously](http://stackoverflow.com/questions/748777/run-gc-collect-synchronously) – Rick Sladkey Jun 18 '11 at 22:46

5 Answers5

14

As MSDN states - Use this method to try to reclaim all memory that is inaccessible.

Anyway, if it does starts Garbage collection you should wait to all finilizers to finish before start benchmarking.

   GC.Collect();

   GC.WaitForPendingFinalizers();
Maxim
  • 7,268
  • 1
  • 32
  • 44
13

Since .NET Framework 4.5 you can specify whether the GC collection should be blocking:

GC.Collect(GC.MaxGeneration, GCCollectionMode.Optimized, blocking: true);

or

GC.Collect(GC.MaxGeneration, GCCollectionMode.Default, blocking: true);

GCCollectionMode.Default currently defaults to GCCollectionMode.Forced

For more details, see:

MSDN: GC.Collect Method (Int32, GCCollectionMode, Boolean)

MSDN: Induced collections - guide

Chris Marisic
  • 32,487
  • 24
  • 164
  • 258
Shocked
  • 627
  • 4
  • 13
  • 1
    Blimey. I didn't know this (new) version of GC.Collect() existed. Do you know if there are any side-effects to having "blocking" set to false ? Certainly, it's *much* faster when using this new version, I just wonder if it's going to break any existing VSTO Excel Addin code.. – Mike Gledhill Jun 02 '16 at 14:30
2

If you want to benchmark your code, it should be done over a course of many iterations and as an average. You are never guaranteed when GC is run in the first place.

Daniel A. White
  • 187,200
  • 47
  • 362
  • 445
2

You should just assume:

  1. GC runs some times, and not some others.
  2. Heavy stuff happens in some unrelated processes some times, and not some others.
  3. Something crazy happens every now and then.

And hence do several iterations of the tests you are doing, remove the highest and lowest (assume they were flukes either way) and average what's left. This will give you meaningful comparisons.

Jon Hanna
  • 110,372
  • 10
  • 146
  • 251
0

The way GC in .Net works is to stop all threads (at least for a part of full collection, which is what GC.Collect() does). So you could say it is very synchronous, it's not blocking just one thread, but all of them. And calling GC.Collect() will perform the collection and return only after it finished, so, GC.Collect() is the way to run it synchronously.

There is one part related to GC that is run on a background thread – finalizers. If you want to make sure all finalizers are finished before you run your benchmark and that all finalized objects are actually collected, use:

GC.Collect();
GC.WaitForPendingFinalizers();
GC.Collect();

That being said, there is no way to make sure that the GC won't run. And I don't understand why do want to do that. If, for example, your code is creating lots of temporary objects, the GC should be part of your benchmark, for better or worse, you should not try to exclude it.

svick
  • 236,525
  • 50
  • 385
  • 514
  • 4
    No. the .NET GC is not always a stop-the-world GC. In fact, concurrent GC is the most common. http://msdn.microsoft.com/en-us/library/at1stbec.aspx. – R. Martinho Fernandes Jun 18 '11 at 23:04
  • Hmm, that link doesn't say much. Do you know where I could get more information about what exactly does concurrent GC mean and how does it work? (And I mean specifically in .Net.) – svick Jun 18 '11 at 23:12
  • 2
    See this: http://msdn.microsoft.com/en-us/library/ee787088.aspx#concurrent_garbage_collection – R. Martinho Fernandes Jun 18 '11 at 23:18
  • If I were answering this question I would have said the same thing as you in your last statement. You're right, if the GC runs during a test as a result of that test creating lots of temp objects then it should be part of the benchmark. I guess what I really want is just to do a GC before each benchmark to ensure a GC isn't ran during a test as a result of late cleanup of a previous test if that makes sense. In other words, ideally one test should not effect the results of a following test. – CodeAndCats Jun 18 '11 at 23:18