2

I know this may seem like a duplicate, but I think this specific case may be a bit different.

In my MVC application, I have a ViewModel containing a big List used to display a table similar to an Excel sheet. each MyComplexClass contains a list of MyComplexClass and a list of MyComplexColumn.

This makes a pretty big memory usage, but now I have a problem. I am supposed to write a method that cleans my big table, and load a different set of data into it. I could write something like:

    MyViewModel.Lines = new List<MyComplexClass>();
    MyViewModel.LoadNewSetOfData(SetOfData);

But, comming from a C background, explicitly losing my reference on the old List is not something I can do, and continue looking at my face in the mirror every morning.

I saw Here, Here, and Here, that I can set the reference to null, and then call

GC.Collect()

But I was told that I was not really best practice, especially because it may really affects performance, and because I have no way to know if the GC has disposed of this specific memory allocation.

Isn't there any way I can just call something like Free() and live on?

Thank you

Community
  • 1
  • 1
Waterfrag
  • 517
  • 4
  • 20
  • 3
    Just live on and let the GC do its job. – Anton Gogolev Jun 14 '16 at 13:09
  • *"This makes a pretty big memory usage"* - so do you really get out of memory or just worrying about it? If second option - just don't take it seriously, GC will do its job fine in most cases. – Andrey Korneyev Jun 14 '16 at 13:09
  • Yeah, the GC is better at it's job than you, it's in no way at all shameful to not explicitly free memory. – Master117 Jun 14 '16 at 13:10
  • I just don't understand why I can't do it myself. I can understand why it is useful to have a GC when you get unwanted memory leaks, but in the case I know I won't be using this space, I should be able to tell the system "Hey there dude, you can take it back, I don't need this anymore" – Waterfrag Jun 14 '16 at 13:17
  • @MarrowGnawer - "I can understand why it is useful to have a GC when you get unwanted memory leaks" - No, you don't, as the GC **cannot** get rid of unwanted memory leaks. The GC is just very good at making sure it gets rid of objects that are no longer referenced (these are not leaks). If you have leaks that's unmanaged memory that you must explicitly dispose of. – Enigmativity Jun 14 '16 at 13:20
  • A memory leak is usually caused when somehow you retain an unintended reference to an object. That prevents garbage collection from freeing it. As a result that memory never gets reclaimed. In that circumstance garbage collection isn't going to reclaim the memory whether it runs automatically or you call it explicitly. But that is usually only an issue when you're dealing with COM objects or other unmanaged code. That's why it's called "managed," because as long as the objects are created within the framework then it keeps track of them and releases them. – Scott Hannen Jun 14 '16 at 13:24

2 Answers2

5

Don't worry about it! Trying to "encourage" the garbage collector to reclaim memory isn't a great idea - just leave it to do its work in the background.

Just load your different set of data. If memory is getting low the GC will kick in to reclaim the memory without you having to do anything, and if there's plenty of memory available then you'll be able to load the new set without taking the hit of a garbage collection.

Sean
  • 60,939
  • 11
  • 97
  • 136
  • So there is absolutely no way in c# to free a memory space? I mean, other than writing a dll in C, and call it in my c# code? – Waterfrag Jun 14 '16 at 13:20
  • @MarrowGnawer - perhaps the question is why are you worrying so much about freeing the memory? – Sean Jun 14 '16 at 13:23
  • @MarrowGnawer - I know, I've been there too! But trust me, relax and learn to trust the garbage collector! – Sean Jun 14 '16 at 13:29
1

The short answer - don't worry about garbage collection. The only time I'd be concerned is if you're putting massive amounts of objects and data in a place where they might not get properly garbage collected at all. For example, you store tons of per-user data in ASP.NET session, and it sits there for a long time even though the user visits a few pages and leaves.

But as long as references to objects are released (as when they go out of scope) then garbage collection will do its job. It might not be perfect, but it's really, really good. The work and thought that went into developing good garbage collection in most cases probably exceeds the work that we put into developing the applications themselves.

Although we have the ability to trigger it, the design of the .NET framework deliberately allows us to focus on higher-level abstractions without having to worry about smaller details like when the memory is freed.

Scott Hannen
  • 27,588
  • 3
  • 45
  • 62