GC.Collect()

Question

Ok, I\'ve read a couple of topics about it, but here it goes. Let\'s imagine I have an application where basically every now and then I will click on a button, a lot of thin

Answer 1

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.

Answer 2

Yea as mentioned in other posts GC know when to start collection better than you, the factor that no buttons are clicked in your application doesn't mean that it is the time to start cleaning, GC is doing some kind of lockings when moving the objects, so this may cause low performance if you will abuse GC.Collect

Answer 3

Normally the GC is only called if you attempt to allocate new memory. If you don't run out of memory, you obtain 0% performance improvement from calling the GC. You have to have a pretty insanely resource intensive application to even come close to the limits of RAM on todays computers.

If you program has lots of external resources(like files or COM/DCOM references), you potentially would want to call the GC.

If calling the GC will give you peace of mind, then go ahead. It likely won't help, but it certainly wouldn't hurt.

Answer 4

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

Answer 5

To know when to call GC.Collect(), you'd need to know details of the specific collector involved with the runtime along with detailed information about a weak point that you can solve with the collection.

In other words, if you really know when you need to call GC.Collect(), and it's not something you'd done poorly in other code, then you probably work for CLR Internals and can just fix the problem.

Answer 6

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.