Memory Management
-
Short answer Gc.Collect;. Long answer - don't. The framework has been optimised already, fighting it like this will only hurt performance. What's the issue, are you running out of memory ? Christian Graus - Microsoft MVP - C++
-
Right now I am not running out of memory. But when the code will go into production I am sure that I will have a high risk to run out of memory.
VickyC# wrote: But when the code will go into production I am sure that I will have a high risk to run out of memory. From opening a few forms ? What's on them ? If it's bitmaps, make sure you dispose of them. If they are just normal forms, are you expecting to run on machines with < 64 MB of memory ? Christian Graus - Microsoft MVP - C++
-
VickyC# wrote: But when the code will go into production I am sure that I will have a high risk to run out of memory. From opening a few forms ? What's on them ? If it's bitmaps, make sure you dispose of them. If they are just normal forms, are you expecting to run on machines with < 64 MB of memory ? Christian Graus - Microsoft MVP - C++
Well here is the pattern, it just keeps tagging some memory and then at some point memory is released but it never reaches the initial amount. So when the app will run for an extendend period of time it seems that I will have an issue. Yes, my question is when a form is disposed do all the children get disposed? Or I need to dispose each one.
-
Well here is the pattern, it just keeps tagging some memory and then at some point memory is released but it never reaches the initial amount. So when the app will run for an extendend period of time it seems that I will have an issue. Yes, my question is when a form is disposed do all the children get disposed? Or I need to dispose each one.
VickyC# wrote: Well here is the pattern, it just keeps tagging some memory and then at some point memory is released but it never reaches the initial amount. So when the app will run for an extendend period of time it seems that I will have an issue. You cannot run out of memory, because if things get to a critical level, the framework will force a collectitself. It will also perform a collect periodically. Any objects that are not used for long are quickly cleaned up. Objects that are used for a long time are cached for a long time, which is what you're fighting when you force the collection yourself. VickyC# wrote: Yes, my question is when a form is disposed do all the children get disposed? Or I need to dispose each one. You don't need to dispose of any forms. You only need to dispose of resources such as bitmaps. But yes, if there is an object tree and the object impliments IDisposable, the dispose method should clean all of it. Christian Graus - Microsoft MVP - C++
-
VickyC# wrote: Well here is the pattern, it just keeps tagging some memory and then at some point memory is released but it never reaches the initial amount. So when the app will run for an extendend period of time it seems that I will have an issue. You cannot run out of memory, because if things get to a critical level, the framework will force a collectitself. It will also perform a collect periodically. Any objects that are not used for long are quickly cleaned up. Objects that are used for a long time are cached for a long time, which is what you're fighting when you force the collection yourself. VickyC# wrote: Yes, my question is when a form is disposed do all the children get disposed? Or I need to dispose each one. You don't need to dispose of any forms. You only need to dispose of resources such as bitmaps. But yes, if there is an object tree and the object impliments IDisposable, the dispose method should clean all of it. Christian Graus - Microsoft MVP - C++
-
VickyC# wrote: for all practical purposes it seems good enough for watching what happens to memory The Task Manager is actually lousy at showing what's really going on inside the virtual machine that is the managed execution environment of the .NET Framework. What you're seeing in Task Manager is the amount of memory reserved for the entire virtual machine that you application runs in, not just your application code. RageInTheMachine9532 "...a pungent, ghastly, stinky piece of cheese!" -- The Roaming Gnome
Not only that, but you'll see this same phenomenon with unmanaged apps, where you allocate memory, then free it, but Task Manager does not show you going back to the original amount. If you don't believe me, write yourself a little C++ app that allocates a few meg on the click of a button and frees it on another click and watch in Task Manager. So, it is not only the CLR that does this thing of not fully releasing dereferenced memory, but also the OS itself. That is because they both have the expecatation that an app will probably repeat its past behavior, so why waste all the extra cycles completely releasing the memory, then going to reallocate it a short time later. If that memory really is not used by the app again and other apps need it, that more complete deallocation will take place. You can use the
SetProcessWorkingSetSize()API function to hurry up and "collect" the the memory that your app has released. I had an app that would use a few meg of memory infrequently and got some complaints that it was taking up too much memory (people looking at Task Manager); I added a call toSetProcessWorkingSetSize()right before it went into its "background" mode and it showed up quite tiny in Task Manager (I forget the exact numbers, but it went from several meg, to a few K). Keep in mind though, that this is only for cosmetic purposes and doesn't really make your app use memory more efficiently or anything like that (and in fact may make your app perform worse, since when it does try to use that memory again, it will probably be slower in getting it). Matt Gerrans -
VickyC# wrote: Well here is the pattern, it just keeps tagging some memory and then at some point memory is released but it never reaches the initial amount. So when the app will run for an extendend period of time it seems that I will have an issue. You cannot run out of memory, because if things get to a critical level, the framework will force a collectitself. It will also perform a collect periodically. Any objects that are not used for long are quickly cleaned up. Objects that are used for a long time are cached for a long time, which is what you're fighting when you force the collection yourself. VickyC# wrote: Yes, my question is when a form is disposed do all the children get disposed? Or I need to dispose each one. You don't need to dispose of any forms. You only need to dispose of resources such as bitmaps. But yes, if there is an object tree and the object impliments IDisposable, the dispose method should clean all of it. Christian Graus - Microsoft MVP - C++
Christian Graus wrote: You don't need to dispose of any forms. Not entirely true. If you call
.ShowDialog()on any form, you have to.Dispose()it when you're done with it. From the MSDN Gospel: When a form is displayed as a modal dialog box, clicking the close form button (the button with an "X" at the top right of the form) causes the form to be hidden and the DialogResult property to be set to DialogResult.Cancel. Unlike modeless forms, the Close method is not called by the .NET Framework when the user clicks the close form button of a dialog box or sets the value of the DialogResult property. Instead the form is hidden and can be shown again without creating a new instance of the dialog box. Because a form displayed as a dialog box is not closed, you must call the Dispose method of the form when the form is no longer needed by your application. RageInTheMachine9532 "...a pungent, ghastly, stinky piece of cheese!" -- The Roaming Gnome -
Christian Graus wrote: You don't need to dispose of any forms. Not entirely true. If you call
.ShowDialog()on any form, you have to.Dispose()it when you're done with it. From the MSDN Gospel: When a form is displayed as a modal dialog box, clicking the close form button (the button with an "X" at the top right of the form) causes the form to be hidden and the DialogResult property to be set to DialogResult.Cancel. Unlike modeless forms, the Close method is not called by the .NET Framework when the user clicks the close form button of a dialog box or sets the value of the DialogResult property. Instead the form is hidden and can be shown again without creating a new instance of the dialog box. Because a form displayed as a dialog box is not closed, you must call the Dispose method of the form when the form is no longer needed by your application. RageInTheMachine9532 "...a pungent, ghastly, stinky piece of cheese!" -- The Roaming GnomeDave Kreskowiak wrote: clicking the close form button (the button with an "X" at the top right of the form) causes the form to be hidden and the DialogResult property to be set to DialogResult.Cancel. Bloody hell - I didn't know that. How stupid !!! So clicking OK or Cancel will destroy it, but clicking the X does not ? Christian Graus - Microsoft MVP - C++
-
Dave Kreskowiak wrote: clicking the close form button (the button with an "X" at the top right of the form) causes the form to be hidden and the DialogResult property to be set to DialogResult.Cancel. Bloody hell - I didn't know that. How stupid !!! So clicking OK or Cancel will destroy it, but clicking the X does not ? Christian Graus - Microsoft MVP - C++
:laugh: Silly! Isn't it? RageInTheMachine9532 "...a pungent, ghastly, stinky piece of cheese!" -- The Roaming Gnome
-
:laugh: Silly! Isn't it? RageInTheMachine9532 "...a pungent, ghastly, stinky piece of cheese!" -- The Roaming Gnome