Prevent .Net Garbage Collection for Short Period of Time

Prevent .NET Garbage collection for short period of time

.NET 4.6 added two new methods: GC.TryStartNoGCRegion and GC.EndNoGCRegion just for this.

Is it possible to stop .NET garbage collection?

Not really. You can give the GC hints via methods like GC.AddMemoryPressure or GC.RemoveMemoryPressure but not stop it outright.

Besides, garbage collection is not that intensive of a process. Programmers very rarely ever worry about it.

Suppressing C# garbage collection

Unless you can confirm that the garbage collector is actively slowing the performance of your application, you should not take steps to cripple the functionality of your runtime environment.

Judging from your question, you have not confirmed that the GC is a problem. I severely doubt that it is.

Optimize only what needs to be optimized.

How to avoid garbage collection in real time .NET application?

Don't delete them right away. Calling the garbage collector for each object is a bad idea. Normally you really don't want to mess with the garbage collector at all, and even time critical processes are just race conditions waiting to happen if they're that sensitive.

But if you know you'll have busy vs light load periods for your app, you might try a more general GC.Collect() when you reach a light period to encourage cleanup before the next busy period.

How to reduce Garbage Collection performance Overhead

Well basically you should reduce the work for the garbage collector. There a certain 'patterns' which produce a lot of work.

• Avoid having many objects with finalizers. Finalizers impose additional work on the garbage collector, because a object with a finalizer has to be collected twice.
• Avoid the 'midlife'-crisis. The .NET GC (on the desktop) is generational GC. When the object survive the first collection, but 'die' shortly after, the GC has done a lot of work for nothing. (coping to the second generation, collecting again, etc). So try to optimize the life-time of you objects in a way that they either die very quickly, or survive for a long, long time.
• Reduce unnecessary allocations. For example by using value type wisely. Or doing the work in a less memory-intensive way.

So in your case I guess that you either you've a 'midlife'-crisis with the short lived lists. Or you simple allocate list like mad.

In the first case: Try to make the life-span of the lists shorter. I can't tell you how the solution looks like for your application.

In the second case: Try to avoid allocation so many lists. Maybe you can use proper value-types? Or fixed sized arrays? Or change the structure of the code in such a way that less lists are needed?

Anyway, I would recommend to profile you applicaition and look how much you memory you allocate and how much can be collected in the first generation.

Do event handlers stop garbage collection from occurring?

For the specific question "Will pClass be garbage collected": the event subscription has no effect on the collection of pClass (as the publisher).

For GC in general (in particular, the target): it depends whether MyFunction is static or instance-based.

A delegate (such as an event subscription) to an instance method includes a reference to the instance. So yes, an event subscription will prevent GC. However, as soon as the object publishing the event (pClass above) is eligible for collection, this ceases to be a problem.

Note that this is one-way; i.e. if we have:

publisher.SomeEvent += target.SomeHandler;

then "publisher" will keep "target" alive, but "target" will not keep "publisher" alive.

So no: if pClass is going to be collected anyway, there is no need to unsubscribe the listeners. However, if pClass was long-lived (longer than the instance with MyFunction), then pClass could keep that instance alive, so it would be necessary to unsubscribe if you want the target to be collected.

Static events, however, for this reason, are very dangerous when used with instance-based handlers.

---

Related Topics