Is it smart to call gc.Collect()?

[msjonathan]

Hej,

We 're working on an application that displays a lot of data, we have some problems with the memory usage (displaying data in grid, see some linked data, ...) when closing the grid the memory usage does not drop, but when we call the Garbage collector in the disposed event. The memory drops phenomenal.

this is code we execute.

[DllImportAttribute("kernel32.dll", EntryPoint = "SetProcessWorkingSetSize", ExactSpelling = true, CharSet = CharSet.Ansi, SetLastError = true)]
      private static extern int SetProcessWorkingSetSize(IntPtr process, int minimumWorkingSetSize, int maximumWorkingSetSize);

      /// <summary>
      /// Will request to flush the memory
      /// </summary>
      public static void FlushMemory()
      {
         GC.Collect();
         GC.WaitForPendingFinalizers();

         if (Environment.OSVersion.Platform == PlatformID.Win32NT)
            SetProcessWorkingSetSize(Process.GetCurrentProcess().Handle, -1, -1);
      }

And how we call it in the disposed event

MemoryManagement.FlushMemory();

My question is :) is it smart to do so? or if it just a fake solution?

Kind regards.

Greetz,

Jonathan

[GaryTexmo]

There's a few threads on here about garbage collection in C#, you might be able to find them in a search. Actually, if you can't find them can you please let me know?

Anyway, the general idea is that C# is supposed to be smart enough to release memory for you when it's needed, but I've actually encountered the same issue you are in almost the same scenario, oddly enough. You would think closing the grid (an thus releasing any references) would take care of it, but for some reason it doesn't do it soon enough. You know the memory is marked to be free because the manual collect takes care of it. We ultimately had to take the same approach as you, so if you're in this position I think you're doing the right thing.

There is one gotcha though that you need to be aware of. Manually calling Collect on the GC class does a collect for all .NET processes currently running on the Framework (or at least, that's what I've understood from various readings and discussions). So when you do this, other .NET applications running on the same system could experience a performance hit, but I don't think there would be any other issues.

[msjonathan]

hej,
@GaryTexmo: thanks for the fast response. I'll perform a search on the forum. Indeed we read also about GC, and we wanted to be sure that we could perform the collect.

Kind regards.

Greetz,

Jonathan

[Plater]

I do not believe it effects other applications. (In fact I think it's related to your loaded AppDomain, but it might be program wide)
The description about "generation s" in the gc.collect() can be confusing, but just think of it as "age" of an object reference.
I've seen a lot of people say it's bad (read: unnecessary) to call Collect().
If you are doing an mixing of managed/unmanaged(COM Objects) code, you should read into the keep-alive system if you plan to call .Collect()

Otherwise, I myself like to call it after finishing a large task. (Run task with large dataset, dispose of everything, call Collect()) I had software sitting at 600megs of used data, I called a dispose and a collect and i'd be down to 34megs.

[GaryTexmo]

I freely admit I can't remember where I heard about the being tied to other applications... it's been a while since I've looked into it, but I seem to recall a thread on here about it where someone either mentioned that or linked me to an article that said that.

I'd happily be wrong on that one... I was hoping msjonathan would find the thread in their search :) I haven't had a chance to go digging for it. Of course, you put the bug in my head... I can't find where I came up with that so maybe I'm just making it all up, but I had it confused anyway.

Here is something I found in one of the other threads I posted though...

http://blogs.msdn.com/b/ricom/archive/2004/11/29/271829.aspx

[Plater]

Yeah, I did a poor job articulating it, but Rule #2 was my situation.