Is it a good idea to force garbage collection to be sure that GC won't check quite large objects later?

Question

I have created server application that has to process some data (that is quite heavy process) before it starts listening clients. In the result it allocates memory (approximately 30MB) that will never be used but once.

Will it give me a benefit to force garbage collection? Or let GC do its work?

Also I have to use .NET 3.5 and as far as I know garbage collection will interrupt thread that's why I came to forcing Garbage Collector.

Answer 1

You don't say how you are allocating that 30MB of memory, but it matters greatly. If you are allocating unmanaged memory, the GC doesn't know about it (though you can tell it with method GC.AddMemoryPressure). In that case, you should implement IDisposable on the class that handles the unmanaged memory and you should explicitly call Dispose when you are done with the object.

If you are allocating managed memory, just let the GC do its work, unless:

• You just happen to know that after you have finished with the object you will always have a lull in activity and
• You've actually observed evidence that the GC is causing performance problems at later point in time.

Answer 2

Part of the point of a managed language is that you will (presumably) not have to worry about garbage collection, ever. There will only be very specific circumstances where manually calling the garbage collector will be useful, and this is almost certainly not one of them.

You can read about some of the semantics behind the GC and what makes it fast as opposed to slow here, which might be good theoretical reading so you are aware of what's going on.

In the meantime, for your specific problem, I think you should take a look at the IDisposable interface. If you have a specific object that is big and you are concerned about, implementing the IDisposable interface on it will allow you to wrap the work in a using statement, which guarantees that the object will be disposed of the instant you're done with it. On the flip side of that particular coin, it guarantees that there will be an active, open handle to that large object so there's no way it will be picked up by the GC until the using statement ends.

This will probably address your problem a lot better than trying to manually screw around with the GC, which is something of a black box to end programmers by design.

Answer 3

OK look, garbage collection is still just a heuristic, it's trying to do the best guess it can in general, but it may be possible that you have a legitimate claim at knowing better than it at particular times.

Take for example a game with a lot of assets. When you switch to a new zone, you pop up a loading screen and start loading your new data, releasing references to the old data. It won't get collected yet because you haven't hit your threshold, but you might hit it soon as you're starting to create your little matrices every frame to present your game, and then you'll get a (possibly noticeable) stutter as you're unloading hundreds of megs of data and moving everything else around to compact the queues.

Now you can instead force a collect after the new assets were loaded, since the user is already in "idle" mode, staring at your progress bar, he won't notice the little stutter and your game will seem smoother overall afterwards.

The real trick then becomes knowing when to interfere and when not to. When in doubt, don't -- that collection will happen regardless, and making it happen more often will only make your application seem more stuttery. You need something to "hide" it, like a long task that locks your application with a progress bar that somehow generates a lot of finalized objects -- really a game loading screen is the only thing I can come up with, but YMMV.