Click here to Skip to main content
15,909,530 members
Please Sign up or sign in to vote.
1.00/5 (3 votes)
See more:
Hi,Do I want to destroy the used memory after the child forms.

Forms received prior to the child's memory performance.
Image 1
Forms received after the child's memory performance.
Image 2
From memory after closing the child form.
Image 3
Posted

First, stop looking in Task Manager to see how much memory your app is actually using. It's lying to you.

The numbers you're looking at in Task manager are what the .NET CLR has RESERVED for your application, NOT what it's actually using.

.NET maintains a Managed Heap. It gets a chunk of memory from Windows and puts it into the managed heap. When you're application allocated an object, it gets the memory from the managed heap. When you're done with the object, the memory goes back into the managed heap.

The .NET CLR will free up any memory it can and return that back to Windows if needed.

What Task Manager is showing you is how much memory Windows has given up to the .NET CLR managed heap.

If you want to see what your app is really using, using PerfMon and the .NET Memory performance counters, or a .NET memory profiler[^].
 
Share this answer
 
Comments
Ali91Asadi 28-Sep-12 14:47pm    
Thank you.
BillWoodruff 28-Sep-12 19:34pm    
+5 Excellent answer, Dave !
fjdiewornncalwe 28-Sep-12 20:43pm    
+5. Funny that solution 3 got the "correct" tag though...
Normally, you don't need to free up memory in managed systems, because the Garbage Collector (GC) will do it for you. The destruction and reclaiming of the memory is based in the concept of reachability of an object:
http://en.wikipedia.org/wiki/Garbage_collection_%28computer_science%29[^].

It does not mean that you cannot have memory leaks, but first, you need to understand the memory leak. When you do some operations, and then return to the same place in the state diagram of your finite state machine (http://en.wikipedia.org/wiki/Finite-state_machine[^]), the number of the reachable objects is supposed to be the same, and they should be equivalent to the objects which existed at the same point before. The example is: you open and close several files in some editor, and later you close them all. You should have as many reachable objects as before you opened the very first one. If this is the case, everything is all right. Nothing to worry about.

Does it mean you hold the same exact amount of memory? Yes and no. The memory is reclaimed after the object becomes unreachable, but the exact moment of time is not guaranteed. It can happen sooner or later. That is yet another reason why the Task Manager should not be used to assess the memory usage. And you can use one of the memory debuggers, but you should clearly understand what's going on. Please see:
http://en.wikipedia.org/wiki/Memory_debugger[^].

Now, if everything is so good, how can you have memory leaks? First of all, by design. Imagine you work with files as I describe above, but you also cache some data to accelerate some search procedures. The problem is the life time of the cache: it should go beyond the life time of each file and be about the life time of the whole process. You can close all files, but what if you forget to clean out the data related to the file? It will remain in cache and so continue to be reachable. This is the leak. You can still allow reclaiming of the memory, if such cache (collection, some dictionary, or something) uses weak references instead:
http://en.wikipedia.org/wiki/Weak_reference[^],
http://msdn.microsoft.com/en-us/library/system.weakreference.aspx[^].

Finally, your application can also use managed memory via P/Invoke or some mixed-mode assembly, which is possible with C++/CLI. Please see:

http://en.wikipedia.org/wiki/P/Invoke[^],
http://msdn.microsoft.com/library/en-us/vcmxspec/html/vcmg_PlatformInvocationServices.asp[^],
http://www.codeproject.com/csharp/EssentialPInvoke.asp[^];
http://en.wikipedia.org/wiki/C%2B%2B/CLI[^],
http://www.ecma-international.org/publications/standards/Ecma-372.htm[^],
http://msdn.microsoft.com/en-us/library/dtefa218.aspx[^].

In this case, unmanaged memory should be explicitly reclaimed. It is very usual to do it in the implementation of the method Dispose of the interface System.IDisposable:
http://msdn.microsoft.com/en-us/library/system.idisposable.aspx[^].

It's important to see if some type you use implements this interface and not to forget to dispose it. It's the best to use the using statement whenever possible:
http://msdn.microsoft.com/en-us/library/yh598w02%28v=vs.110%29.aspx[^].

[EDIT #1]

Please see my past answers:
Garbage collectotion takes care of all the memory management[^],
deferring varirable inside the loop can cuase memory leak?[^],
Best way to get rid of a public static List Causing an Out of Memory[^].

[EDIT #2]

Please also understand that using MDI is bad thing. Please see:
http://en.wikipedia.org/wiki/Multiple_document_interface#Disadvantages[^].

Please also see my past answers:
Question on using MDI windows in WPF[^],
MDIContainer giving error[^],
How to set child forms maximized, last childform minimized[^].

…as well as this answer:
How to Create MDI Parent Window in WPF?[^].

[EDIT #3]

Detection of reachability is smart enough. What happens if some object A has reference to B, B to C, and C to A? Will they be reclaimed, if there are no other references to them? Yes, they will. You can try it.

[EDIT #4]

As a strong rule of thumb, it's the best not to touch GC object; nothing essential will be changed, at best, or things could even go worse.

—SA
 
Share this answer
 
v6
Comments
BillWoodruff 28-Sep-12 19:33pm    
+5 One of your very best, Sergey :)
Sergey Alexandrovich Kryukov 28-Sep-12 19:36pm    
Thank you, Bill.
--SA
fjdiewornncalwe 28-Sep-12 20:43pm    
+5. Of course.
Sergey Alexandrovich Kryukov 28-Sep-12 21:17pm    
Thank you, Marcus.
--SA

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)



CodeProject, 20 Bay Street, 11th Floor Toronto, Ontario, Canada M5J 2N8 +1 (416) 849-8900