Minimize window to gain memory space???
-
Hi there, Check this out. It happends with all programs i have installed. I have WinXP SP2. When i open any program, lets say Winamp for example, the program starts with 11.000 KiB of memory usage, i minimize the program and immediatly restore it and now it uses 1.500 KiB. Why is this happening? Do applications need to start minimized and then manually restored to make use (and show in the task manager) of the proper memory space? Again, it happends with every windowed app. This issue is kind of important to me right now because i have to show the efficiency of a demo, in terms of response time and memory usage. Any thoughs about this? Please try it. Thanks.
-
Hi there, Check this out. It happends with all programs i have installed. I have WinXP SP2. When i open any program, lets say Winamp for example, the program starts with 11.000 KiB of memory usage, i minimize the program and immediatly restore it and now it uses 1.500 KiB. Why is this happening? Do applications need to start minimized and then manually restored to make use (and show in the task manager) of the proper memory space? Again, it happends with every windowed app. This issue is kind of important to me right now because i have to show the efficiency of a demo, in terms of response time and memory usage. Any thoughs about this? Please try it. Thanks.
First, stop looking at Task Manager to get your memory stats for your app. It's lying to you. Next, I suggest reading up on .NET Memory Management and Garbage Collector to understand how it really works. A .NET application runs in something like a virtual machine, sort of like Java does. What Task Manager is showing you is the memory that is RESERVED for the process, NOT what your app is actually using. Since the .NET CLR handles memory management for your application, it has to get memory from Windows to allocate to your application. This chunk of memory is the Managed Heap and all of your application objects are allocated from it. When your app frees an object, the memory goes back into the Managed Heap, not back to Windows. This is why your app appears to use more memory than it actually does. The .NET CLR tries to keep this pool of memory at a resonable level, constantly watching how your app allocates objects and trying to predict when it's going to need more managed heap. It doesn't take near as much time to allocate an object in the Managed Heap than if it had to go to Windows to request more memory, add it to the heap, then allocate your object. The reverse is also true. If the CLR determines that there is an over abundance of unused Heap, it can return some of that memory back to Windows. Or, can even release as much memory as possible if Windows starts to run low and needs it back. When you minimize the app, it's no longer in the foreground. The .NET CLR trims back the Managed Heap to something closer to what your app is actually using and returns that released memory back to Windows.
A guide to posting questions on CodeProject[^]
Dave Kreskowiak -
First, stop looking at Task Manager to get your memory stats for your app. It's lying to you. Next, I suggest reading up on .NET Memory Management and Garbage Collector to understand how it really works. A .NET application runs in something like a virtual machine, sort of like Java does. What Task Manager is showing you is the memory that is RESERVED for the process, NOT what your app is actually using. Since the .NET CLR handles memory management for your application, it has to get memory from Windows to allocate to your application. This chunk of memory is the Managed Heap and all of your application objects are allocated from it. When your app frees an object, the memory goes back into the Managed Heap, not back to Windows. This is why your app appears to use more memory than it actually does. The .NET CLR tries to keep this pool of memory at a resonable level, constantly watching how your app allocates objects and trying to predict when it's going to need more managed heap. It doesn't take near as much time to allocate an object in the Managed Heap than if it had to go to Windows to request more memory, add it to the heap, then allocate your object. The reverse is also true. If the CLR determines that there is an over abundance of unused Heap, it can return some of that memory back to Windows. Or, can even release as much memory as possible if Windows starts to run low and needs it back. When you minimize the app, it's no longer in the foreground. The .NET CLR trims back the Managed Heap to something closer to what your app is actually using and returns that released memory back to Windows.
A guide to posting questions on CodeProject[^]
Dave KreskowiakGreat answer Dave. I think every developer needs to get a basic understanding of the .Net CLR. Sounds like you read my book. :laugh: (I haven't wrote any books)
The mind is like a parachute. It doesn’t work unless it’s open.
-
Great answer Dave. I think every developer needs to get a basic understanding of the .Net CLR. Sounds like you read my book. :laugh: (I haven't wrote any books)
The mind is like a parachute. It doesn’t work unless it’s open.
That's OK. I don't read any books, so there's really no need to write one.
A guide to posting questions on CodeProject[^]
Dave Kreskowiak -
First, stop looking at Task Manager to get your memory stats for your app. It's lying to you. Next, I suggest reading up on .NET Memory Management and Garbage Collector to understand how it really works. A .NET application runs in something like a virtual machine, sort of like Java does. What Task Manager is showing you is the memory that is RESERVED for the process, NOT what your app is actually using. Since the .NET CLR handles memory management for your application, it has to get memory from Windows to allocate to your application. This chunk of memory is the Managed Heap and all of your application objects are allocated from it. When your app frees an object, the memory goes back into the Managed Heap, not back to Windows. This is why your app appears to use more memory than it actually does. The .NET CLR tries to keep this pool of memory at a resonable level, constantly watching how your app allocates objects and trying to predict when it's going to need more managed heap. It doesn't take near as much time to allocate an object in the Managed Heap than if it had to go to Windows to request more memory, add it to the heap, then allocate your object. The reverse is also true. If the CLR determines that there is an over abundance of unused Heap, it can return some of that memory back to Windows. Or, can even release as much memory as possible if Windows starts to run low and needs it back. When you minimize the app, it's no longer in the foreground. The .NET CLR trims back the Managed Heap to something closer to what your app is actually using and returns that released memory back to Windows.
A guide to posting questions on CodeProject[^]
Dave KreskowiakThanks for this clear and concise explanation. Sometimes one doesn't know what one doesn't know - if you know what I mean! 5 from me. :thumbsup:
It’s not because things are difficult that we do not dare, it’s because we do not dare that things are difficult. ~Seneca
-
Great answer Dave. I think every developer needs to get a basic understanding of the .Net CLR. Sounds like you read my book. :laugh: (I haven't wrote any books)
The mind is like a parachute. It doesn’t work unless it’s open.
Richard Blythe wrote:
Sounds like you read my book.
Dave only reads the back of cereal packets. His knowledge of IT is picked up by being in total harmony with the universe.
"WPF has many lovers. It's a veritable porn star!" - Josh Smith
As Braveheart once said, "You can take our freedom but you'll never take our Hobnobs!" - Martin Hughes.
-
Richard Blythe wrote:
Sounds like you read my book.
Dave only reads the back of cereal packets. His knowledge of IT is picked up by being in total harmony with the universe.
"WPF has many lovers. It's a veritable porn star!" - Josh Smith
As Braveheart once said, "You can take our freedom but you'll never take our Hobnobs!" - Martin Hughes.
Pete O'Hanlon wrote:
Dave only reads the back of cereal packets.
How the hell did you know that?! :laugh: No, seriously?
A guide to posting questions on CodeProject[^]
Dave Kreskowiak -
Pete O'Hanlon wrote:
Dave only reads the back of cereal packets.
How the hell did you know that?! :laugh: No, seriously?
A guide to posting questions on CodeProject[^]
Dave KreskowiakI'll send you some box tops... :-D
The mind is like a parachute. It doesn’t work unless it’s open.
-
First, stop looking at Task Manager to get your memory stats for your app. It's lying to you. Next, I suggest reading up on .NET Memory Management and Garbage Collector to understand how it really works. A .NET application runs in something like a virtual machine, sort of like Java does. What Task Manager is showing you is the memory that is RESERVED for the process, NOT what your app is actually using. Since the .NET CLR handles memory management for your application, it has to get memory from Windows to allocate to your application. This chunk of memory is the Managed Heap and all of your application objects are allocated from it. When your app frees an object, the memory goes back into the Managed Heap, not back to Windows. This is why your app appears to use more memory than it actually does. The .NET CLR tries to keep this pool of memory at a resonable level, constantly watching how your app allocates objects and trying to predict when it's going to need more managed heap. It doesn't take near as much time to allocate an object in the Managed Heap than if it had to go to Windows to request more memory, add it to the heap, then allocate your object. The reverse is also true. If the CLR determines that there is an over abundance of unused Heap, it can return some of that memory back to Windows. Or, can even release as much memory as possible if Windows starts to run low and needs it back. When you minimize the app, it's no longer in the foreground. The .NET CLR trims back the Managed Heap to something closer to what your app is actually using and returns that released memory back to Windows.
A guide to posting questions on CodeProject[^]
Dave KreskowiakThanks for the reply. I'm not using the task manager to get the memory stats in my app, i'm using GetProcessMemoryInfo() from the Win32 API wich is the same i guess. The real thing is: Try this minimize-freemem thing with WinRAR and Task Manager. WinRAR is not .NET (.NOT for me ;P ). So, i think .NET is not the issue here. This also applies to Win32 and all subsequent wrappers. Anyway, for my app i'm also using native Win32. Don't know why your reply is strictly related to .NET. "Windows Forms" is not .NET. WinForms is present also in COM programming (VB6 for example) and MFC so i guess i'm not in the wrong forum (unless this forum is specific for the System.Windows.Forms.dll .NET module). .NET or not, my question has been answered anyway ("...What Task Manager is showing you is the memory that is RESERVED for the process, NOT what your app is actually using..."). Thank u very much. -- Modified Monday, August 16, 2010 3:12 AM
-
Thanks for the reply. I'm not using the task manager to get the memory stats in my app, i'm using GetProcessMemoryInfo() from the Win32 API wich is the same i guess. The real thing is: Try this minimize-freemem thing with WinRAR and Task Manager. WinRAR is not .NET (.NOT for me ;P ). So, i think .NET is not the issue here. This also applies to Win32 and all subsequent wrappers. Anyway, for my app i'm also using native Win32. Don't know why your reply is strictly related to .NET. "Windows Forms" is not .NET. WinForms is present also in COM programming (VB6 for example) and MFC so i guess i'm not in the wrong forum (unless this forum is specific for the System.Windows.Forms.dll .NET module). .NET or not, my question has been answered anyway ("...What Task Manager is showing you is the memory that is RESERVED for the process, NOT what your app is actually using..."). Thank u very much. -- Modified Monday, August 16, 2010 3:12 AM
Heinz_ wrote:
So, i think .NET is not the issue here.
Actually, .NET increases this little "problem". Your app may be very small and not use any data at all and still take up 20MB of memory when started. When you minimize/restore the window, the memory "usage" may drop to 500K, or whatever...
A guide to posting questions on CodeProject[^]
Dave Kreskowiak