I can see that several people have gone extreme about not recommending to call GC.Collect.

GC.Collect is there for a reason, here are my recommendation of when and why to call GC.Collect.

  1. In General, don't worry about calling it, GC tunes itself very well and will do the right thing.

  2. Sometimes, you end up in situation where you know for sure that this is the right time to call it, the situation you described above is exactly the right time to call it, in fact Asp.Net calls GC.Collect at certain points that are similar to what you described.

  3. The GC is smart about calling GC.Collect, if you called GC.Collect, the GC can override your decision and still doesn't collect ( you have to set a flag when you call GC.Collect to choose this behavior), this is the recommended way of calling GC.Collect, since you are still letting the GC decides if it is a good time to collect.

  4. Don't take my recommendation is a general statement for calling GC.Collect, you should always avoid calling it, unless you REALLY sure you need to call it, situation like the one you described is exactly why GC.Collect is there.

  5. The benefit you will get from calling it is freeing the garbage quickly, generally you will care about this situation if

    1. You are in low memory situation and want to be eager about collection, if you are in low memory situation, the GC will be aggressive anyway and will kick in automatically if the memory pressure is high on the machine
    2. If you want to avoid getting in low memory situation and you want to collect eagerly.

Hope this helps.
Thanks


It's almost always a premature optimization to worry about calling GC.Collect before you've prototyped or built the application and tested its performance. The GC is usually very good at collecting memory at the appropriate times. It will certainly run a collection while your application is idle, especially if there is memory pressure in the system.

It is much more important that you follow good generational GC allocation practices (small objects, short usage, etc.) and you will likely get the performance characteristics you are wanting. If you still don't have the performance you need, after profiling and good design you might think about GC.Collect as a solution.


There's almost never a good reason to call GC.Collect().

In your case, there is absolutely no reason to call it. If you're idle for an hour, the GC will do its collections.


I'm hoping you're aware that calling GC.Collect doesn't cause more (or less) objects to be collected.

If you're trying to optimize for time, do you know the time GC takes to collect objects in your application? On desktop operating systems (XP, Vista etc..), the CLR uses a concurrent GC, and it can run without suspending all threads in the application for the duration of the collection.

Explicitly calling GC.Collect is not recommended because

  1. It throws the CLR GC Tuning algorithm out of gear. The tuner determines when to trigger a GC automatically, and forcing a manual GC messes with its calculations.

  2. By forcing a collection manually, you can end up promoting objects up a generation - objects which might have been collected in the next GC ( if they were "orphaned" before the GC decided to kick in).

You might find it interesting that .NET 4.0, a GC notification mechanism has been introduced for these kinds of scenarios.