4

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.

Leri
  • 12,367
  • 7
  • 43
  • 60
  • 3
    As far as I know you should rarely have to call the GC yourself using .NET. Only things I know of is when you are using a lot of interop stuff. Why not just dispose your object(s) or use a using construction and let the framework handle it, itself. – Gerald Versluis Jul 19 '12 at 14:10
  • I agree with first answer, GC doesn't like forcing. http://stackoverflow.com/questions/233596/best-practice-for-forcing-garbage-collection-in-c-sharp – Denis Agarev Jul 19 '12 at 14:11
  • I would also agree that it's usually best to let it take care of itself. also garbage collection runs in a background thread, so should not interrupt you application – paul Jul 19 '12 at 14:12
  • @paul No it will since I'm using .NET 3.5 – Leri Jul 19 '12 at 14:14
  • If there are no more references to an object, GC will clean it up for you. Honestly, I think there's a leak somewhere in your code. If you could post your code we could identify the problem. – Diamondo25 Jul 19 '12 at 14:14
  • If that memory is only for a short life, it will probably be in generation 0 of the garbage collector and get cleaned up quickly and fairly quietly. – James Michael Hare Jul 19 '12 at 14:15
  • When you say "never be used but once" are you saying it will be discarded after a single use or you will be holding a reference to it? The former will result in GC, the latter won't. – n8wrl Jul 19 '12 at 14:16
  • @Diamondo25 With a pleasure but then I have to upload whole project. – Leri Jul 19 '12 at 14:17
  • @GeraldVersluis Unfortunately, I use dll-s written not by me for previous processing and I don't have access to code. – Leri Jul 19 '12 at 14:18
  • @n8wrl When I start listening to clients those objects are no more reachable but I am pretty sure that some part of them won't be in generation 0. – Leri Jul 19 '12 at 14:20
  • Unless you're running in an extremely resource-constrained environment, 30MB of RAM is barely a drop, and I don't think you should bother trying to micro-optimize there. – Avner Shahar-Kashtan Jul 19 '12 at 14:21

3 Answers3

4

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.

Blindy
  • 65,249
  • 10
  • 91
  • 131
1

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.

tmesser
  • 7,558
  • 2
  • 26
  • 38
  • Disposing objects would be great but I don't have access to some part of this code. Well I think, I'd better not to force GC unless it will be necessary. – Leri Jul 19 '12 at 14:29
  • If you're using it at all in your code you should at least be able to implement an `IDisposable` wrapper object. It is definitely a little janky to do that, but in the theoretical ideal world without any jankiness you would have access to all the code you are required to use! – tmesser Jul 19 '12 at 14:31
0

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.
dgvid
  • 26,293
  • 5
  • 40
  • 57