Can i use GC.Collect() ?
-
engsrini wrote:
Why i should not use GC.Collect?
Because this is not C++. The GC is written in a highly optimised way to decide for itself when to collect. The more important question is, are your objects marked for collection ? If you didn't call Dispose, then they need to become orphaned in memory, and noticed as such, in order to be eligible for collection.
engsrini wrote:
it has reduced the objects in memory from 23459922 to 13902334 its amazing
Sure, it may force some items that had been marked for 2nd or 3rd generation cleanup to disappear, but this can *hurt* performance. Did your app run faster, or did some number you've fixated on just change ?
engsrini wrote:
Even i have used finally part to null all the objects
If you didn't call Dispose, I'm not sure how much that would help. Either way, let the GC do it's job.
engsrini wrote:
so what has to be taken care while using GC.Collect
Just don't do it, not unless you have a more compelling reason than 'that number just got smaller'
Christian Graus - Microsoft MVP - C++ Metal Musings - Rex and my new metal blog "I am working on a project that will convert a FORTRAN code to corresponding C++ code.I am not aware of FORTRAN syntax" ( spotted in the C++/CLI forum )
Christian Graus wrote:
Sure, it may force some items that had been marked for 2nd or 3rd generation cleanup to disappear, but this can *hurt* performance. Did your app run faster, or did some number you've fixated on just change ?
My application is running normal after using it (may be i didn't do thoruough testing and didn't do remote debugging stuffs), I am not using GC.Collect at all the places.. Whenever the user run the test steps with larger iterations, then i will try that command. One more reason for larger memory i am using lot of images for my applicaition since our application is Touch screen we used lot graphics. So as per your suggestion i will put the dispose method wherever necessary, is there any other way to avoid memory leak or any tool to notify me the memory leaks? also is there anyway to idenify the memory used is huge, i suppose to call GC.Collect.
-
Christian Graus wrote:
Sure, it may force some items that had been marked for 2nd or 3rd generation cleanup to disappear, but this can *hurt* performance. Did your app run faster, or did some number you've fixated on just change ?
My application is running normal after using it (may be i didn't do thoruough testing and didn't do remote debugging stuffs), I am not using GC.Collect at all the places.. Whenever the user run the test steps with larger iterations, then i will try that command. One more reason for larger memory i am using lot of images for my applicaition since our application is Touch screen we used lot graphics. So as per your suggestion i will put the dispose method wherever necessary, is there any other way to avoid memory leak or any tool to notify me the memory leaks? also is there anyway to idenify the memory used is huge, i suppose to call GC.Collect.
engsrini wrote:
My application is running normal after using it
You are missing the point. Was it running normally before ? Odds are, it's less efficient now, but you can't tell, as it works fine, both ways.
engsrini wrote:
So as per your suggestion i will put the dispose method wherever necessary, is there any other way to avoid memory leak or any tool to notify me the memory leaks?
In C++, you got a leak when you didn't call delete. In C#, you get it if you don't call Dispose. Dispose negates any need to GC.Collect, and lets the GC do it's job. There is nothing else to learn, just call Dispose whenever it's there to call. Bitmaps and videos are particular places where this is crucial.
engsrini wrote:
also is there anyway to idenify the memory used is huge, i suppose to call GC.Collect.
NEVER call GC.Collect, did I forget to mention that ? As you were not aware of the Dispose method, I have no doubt that GC.Collect has acted as a band aid on a major problem in your code. Call it, and you will have no issues that GC.Collect could solve.
Christian Graus - Microsoft MVP - C++ Metal Musings - Rex and my new metal blog "I am working on a project that will convert a FORTRAN code to corresponding C++ code.I am not aware of FORTRAN syntax" ( spotted in the C++/CLI forum )
-
Hi chris Thanks for the quick response Why i should not use GC.Collect? Becuase after using GC.Collect function before calling popup display, it has reduced the objects in memory from 23459922 to 13902334 its amazing.. it didn't harm any other part of code..still everything is working fine. Even i have used finally part to null all the objects..and almost in all my code i have done Object=null. I guess i have used lot of singleton object that might be occupying the memory..lot! so what has to be taken care while using GC.Collect
One of the reasons to not call
GC.Collect()that CG hasn't mentioned directly is that when a garbage collection cycle runs, it runs on a different thread than your application. In order for the GC to determine which objects are available for collection, it must freeze your application's main thread. This means that the more time spent in garbage collection, the less time your application has to run. Eventually, you will start to see performance problems as your application spends more time in a frozen state. The best option is to ensure that you dispose of objects as early as possible by callingDisposeor by using theusingsyntax. As you mentioned, setting the object tonullis a good way to inform the GC that the object is eligible for collection because it helps ensure that there are no references to that object remaining. There are a lot of good references on the Dispose pattern and how the garbage collector works. Look at this article, and the references section: http://www.codeproject.com/useritems/idisposable.asp[^]----------------------------- In just two days, tomorrow will be yesterday.
-
Hi chris Thanks for the quick response Why i should not use GC.Collect? Becuase after using GC.Collect function before calling popup display, it has reduced the objects in memory from 23459922 to 13902334 its amazing.. it didn't harm any other part of code..still everything is working fine. Even i have used finally part to null all the objects..and almost in all my code i have done Object=null. I guess i have used lot of singleton object that might be occupying the memory..lot! so what has to be taken care while using GC.Collect
Hello, Apart from the Disposing method (which off course is a "must") you have to make sure that all your delagates are disconnected from your objects. For example your Usercontrol or Form is connected with a global class over an event, and you close the Form (which calls Dispose as well) or Dispose the Usercontrol manually, you have to disconnect the event in your Dispose method. The only reason when I use GC.Collect() is when I'm doing memory profiling before a snapshot is done. Using a memory profiler is what I would also recomend to you, if you whant to be sure that you have no memory leaks. All the best, Martin
-
engsrini wrote:
My application is running normal after using it
You are missing the point. Was it running normally before ? Odds are, it's less efficient now, but you can't tell, as it works fine, both ways.
engsrini wrote:
So as per your suggestion i will put the dispose method wherever necessary, is there any other way to avoid memory leak or any tool to notify me the memory leaks?
In C++, you got a leak when you didn't call delete. In C#, you get it if you don't call Dispose. Dispose negates any need to GC.Collect, and lets the GC do it's job. There is nothing else to learn, just call Dispose whenever it's there to call. Bitmaps and videos are particular places where this is crucial.
engsrini wrote:
also is there anyway to idenify the memory used is huge, i suppose to call GC.Collect.
NEVER call GC.Collect, did I forget to mention that ? As you were not aware of the Dispose method, I have no doubt that GC.Collect has acted as a band aid on a major problem in your code. Call it, and you will have no issues that GC.Collect could solve.
Christian Graus - Microsoft MVP - C++ Metal Musings - Rex and my new metal blog "I am working on a project that will convert a FORTRAN code to corresponding C++ code.I am not aware of FORTRAN syntax" ( spotted in the C++/CLI forum )
-
One of the reasons to not call
GC.Collect()that CG hasn't mentioned directly is that when a garbage collection cycle runs, it runs on a different thread than your application. In order for the GC to determine which objects are available for collection, it must freeze your application's main thread. This means that the more time spent in garbage collection, the less time your application has to run. Eventually, you will start to see performance problems as your application spends more time in a frozen state. The best option is to ensure that you dispose of objects as early as possible by callingDisposeor by using theusingsyntax. As you mentioned, setting the object tonullis a good way to inform the GC that the object is eligible for collection because it helps ensure that there are no references to that object remaining. There are a lot of good references on the Dispose pattern and how the garbage collector works. Look at this article, and the references section: http://www.codeproject.com/useritems/idisposable.asp[^]----------------------------- In just two days, tomorrow will be yesterday.
Scott Dorman wrote:
As you mentioned, setting the object to null is a good way to inform the GC that the object is eligible for collection because it helps ensure that there are no references to that object remaining.
I heared that before but never found a documentation on that topic. Do you have a link to the docu? Thanks All the best, Martin
-
So when you call dispose, you actually just mark that for GC, your not directly removing it?
He who laughs last is a bit on the slow side
No, you're telling it to run custom code which will immediately clean up any unmanaged resources.
Christian Graus - Microsoft MVP - C++ Metal Musings - Rex and my new metal blog "I am working on a project that will convert a FORTRAN code to corresponding C++ code.I am not aware of FORTRAN syntax" ( spotted in the C++/CLI forum )
-
No, you're telling it to run custom code which will immediately clean up any unmanaged resources.
Christian Graus - Microsoft MVP - C++ Metal Musings - Rex and my new metal blog "I am working on a project that will convert a FORTRAN code to corresponding C++ code.I am not aware of FORTRAN syntax" ( spotted in the C++/CLI forum )
-
Scott Dorman wrote:
As you mentioned, setting the object to null is a good way to inform the GC that the object is eligible for collection because it helps ensure that there are no references to that object remaining.
I heared that before but never found a documentation on that topic. Do you have a link to the docu? Thanks All the best, Martin
I'm not sure where it is in any official documentation, but I know it is part of the Framework Design Guidelines (and this updated blog post: DG Update: Dispose, Finalization, and Resource Management[^]. You can also read some more information about it here: Implementing IDisposable and the Dispose Pattern Properly[^]. (Look at the bottom of the "Implementing Dispose" section.)
----------------------------- In just two days, tomorrow will be yesterday.
-
I'm not sure where it is in any official documentation, but I know it is part of the Framework Design Guidelines (and this updated blog post: DG Update: Dispose, Finalization, and Resource Management[^]. You can also read some more information about it here: Implementing IDisposable and the Dispose Pattern Properly[^]. (Look at the bottom of the "Implementing Dispose" section.)
----------------------------- In just two days, tomorrow will be yesterday.