Note
Access to this page requires authorization. You can try signing in or changing directories.
Access to this page requires authorization. You can try changing directories.
Question
Tuesday, April 18, 2006 9:28 AM
hi..
In my application so many variables and XML files are used ..
eventhough after finishing off the work with the file, im closing that.
It works fine with few number of files but when i uses more than 50 files
the application crashes...
So. is there any way to resolve this by clearing the memory.
need help !!!
All replies (13)
Tuesday, April 18, 2006 9:46 AM
You need to make sure you call Dispose on any variable that has that method, before it goes out of scope. But, the garbage collector should ensure that your app never crashes from lack of memory.
Wednesday, April 19, 2006 2:21 PM | 1 vote
"Should" 
I wish it did.
You can force the garbage collector to do an immediate clean-up by calling it's collect method:
GC.Collect()
I was working with an image program before, which loaded images as bitmaps, and cycled over many images in a directory, processing them, saving them, and then moving on (and yes I called .Dispose() after finishing with my imaging objects). I found that if I didn't call the Collect() method, it'd just be thrashing for ages (ie virtual memory paging).
Have a look at task manager's Performance tab, or use Performance Monitor to have a look at the effects of calling this method.
Wednesday, April 19, 2006 2:39 PM
i'm also working alot with bitmaps and never had problems with disposing. note, that task manager does not tell you the whole truth. sometimes even if you dispose an object the memory is not always returned to the system at once - sometimes the CLR holds it for ages until it is really needed somewhere else. Forcing GC.Collect() is rather not a good idea unless you know exactly what you are doing. Putting the GC.Collect() line in a wrong place may kill the performance of your app.
Wednesday, April 19, 2006 3:12 PM
I was using an Image object, and reading/updating EXIF properties on the object. I processed a batch of images (eg. JPEG), each around 3-4Mb in size, one after the other, and used an image stream to open the image. Sometimes I loaded the whole image, sometimes I just opened it in a way that allowed me to modify the EXIF data without loading the whole image. After performing my changes, and re-writing the image (sometimes after making an internal rotation back/forward of 90deg. to avoid re-encoding the compressed image), I disposed of, both the image variable, and the file stream. For some reason, I found after trying many different ways of opening/processing the files, that unless I called GC.Collect(), the memory would run out after processing a couple of hundred files (eg. after processing a batch of files, the memory might be released, but not immediately).
Wednesday, April 19, 2006 11:15 PM
GC.Collect is almost always a bad idea. I write image processing code in C# daily and I've never had memory problems.
Thursday, April 20, 2006 10:47 AM
Wouldnæt an enforced garbage collect be wise to do before a period of intensive processing that'd might require smooth user response? I.e. a game written in C# would perhaps call GC.Collect() after a map has been loaded, right before the gameplay starts....
Thursday, April 20, 2006 10:21 PM
No. You'd call Dispose on the objects in the map, which is what you should do, and then there would not be a problem. The garbage collector is optimised, you should let it do it's job.
Friday, April 21, 2006 11:13 AM
well in theory yes... but not always it is possible. i have a problem with CLR and GC which i describe here: http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=356533&SiteID=1
any ideas?
Monday, April 24, 2006 7:39 AM
I still disagree that calling GC.Collect() is a bad idea. Yes, the GC is highly optimised, but still things come at a cost. I've read some articles on MSDN, and it is clear that the GC will remain inactive in the background, and eventually kick in when things are beginning to get too messy. When you dispose of an object in becomes unavailable to you, but the memory is still allocated until the next GC cycle. So, coming back to my game example, one map might contain, say, some 200 objects, then a new map is loaded with another 200 objects. All the old objects are disposed of, and assuming the GC may not kick in yet, there is a high probability that another object could become spawned in the game, and the GC would find out that the limit was just reached and has to garbage collect right there and then.
GC.Collect() is perhaps a nice way to avoid 'the embarrasing pause'. It should not be used often though, but the GC can't possibly know when is a good time to garbage collect if your program is a constant flow in the background, but there are moments when the user do not expect any immediate response.
Wednesday, July 10, 2013 10:08 AM
hi alwz_nikhil,
according to your describes, i think you may make your code robust .perhaps you can try to
manually dispose your resource in your code .you can use the function in
c#:gc.collect,but this function will recycle all beyond the object of survival,efficiency is very low,please you should think twice before using it .then,you may use （using sentence），it implements IDispose .
Thanks.
Wednesday, July 10, 2013 8:48 PM | 1 vote
Before the GC ever let's things come to a out of Memory Excepton, it already tried to collect all 3 genereations. It can't find any more unsued memory (in a continous block of the size you need).
If you get an out of memory exception, you are using too much memory. Simple as that!
Memory Leaks:
There is one type of memory leak in .NET and one type only. The "Damn, I totally forgot I still held that reference to that" - memory leak. So check, double check and tripple check your code for memory leaks. Especially putting instance References into Lists/Dictionaries and never take them out again is a surefire way to run into a OOM.
Dispose:
Dispose() is generally only implemented into things that handle unmanaged resources. Things like Fileaccess, Network&Database conenctions and the like. Generally calling dispose does not relevantly affect the memory footprint. It has a totally different prupose: Giving back unmanaged resources at a specific time.
One "problem" with GC is that it will remove unused stuff from memory, but you do not know when. Unmanaged resources would be returned when it is collected (when the finalize method is written properly), but usually you want to return them as fast as possible - ideally at a specific moment (right after you have used them). That and only that is what Dispose is for - retruning unmanaged Resources "now".
http://msdn.microsoft.com/en-us/library/fs2xkftw.aspx
How much memory is used:
Properly measuring the real memory usage of a .NET appliaction can be a bit tricky. But generally Task Manager is never a reliable resource.
And of course memory usage is not the most important things anyway - it is one factor, not the main factor:
http://www.itwriting.com/dotnetmem.php
GC Collect:
Calling GCCollect - it is really not a good idea in general. The GC knows that it's runs are costly, so it will avoid to run if not needed. And if has to run it will limit itself to as little work as needed.
Calling GCCollect cannot avoid OOM Exceptions. As I said atthe start - before a OOM is thrown, the GC already collected every single bit it could.
Calling GCCollect has actually a chance to worsen the runtime. Because you collect when not nessesary and Collection will check every single instance in memory. When most of the instances in memory are actually in use, you have a lot of work with no gain. If you just wait for the automatic collection, there is a lot of work with light too high gain.
Resposive UI for long running operation:
If you want the UI to stay responsive during a long operation, use Alternate Threads for the long running Task. See Backgroundworker class, Tasks and await/async keywords.
Let's talk about MVVM: http://social.msdn.microsoft.com/Forums/en-US/wpf/thread/b1a8bf14-4acd-4d77-9df8-bdb95b02dbe2 Please mark post as helpfull and answers respectively.
Thursday, July 11, 2013 2:41 AM | 1 vote
It works fine with few number of files but when i uses more than 50 files
the application crashes...
Sounds like it is time to start debugging your program. A good starting point is to assume that you have done something wrong and try to find what it is that you have done wrong.
The chance that your code is faulty is far, far greater than the chance that the .Net memory management system is faulty.
Trying to debug by making a random guess like "resolve this by clearing the memory" is like trying to fix a car by tossing random pieces of metal at it. Roll up your sleeves, fire up the debugger and start single stepping and examining variables.
Paul Linton
Friday, July 12, 2013 11:23 AM
Hi,
Actually this is a recent response to a 6 year old thread that causes this thread to be on top again. So it's likely the OP doesn't care any more about this issue...
Sometimes I wonder if old thread with no marked answer shouldn't be just deleted ;-)
Please always mark whatever response solved your issue so that the thread is properly marked as "Answered".