Hi,

I am working on a module that uses a lot of object creation (by lot i mean, really lots). So for obvious reasons i have seen Out of Memory exceptions. Now although the objects are being created are too many they go out of scope quickly as well. So i am guessing GC is taking its time to putting the memory back to the heap. My question here is will iDisposable pattern help me is solving my problem?

P.S: any help is appretiated. other patterns, hacks whatever..

Are you using any unmanaged resources?

No unmanaged resources. just class objects. I only want the objects memory that go out of scope to go faster back to the heap.

? They are allready on the heap when they go out of scope.
Any code would perhaps help.

Hi ddanbe, thanks for input. This is my understanding of the memory management by GC (correct me if i am wrong). when the object goes out scope, it does not mean the memory is released then and there. It still occupies the memory, it is released only when GC does his job the next time around. I shall post the code after taking off the BL from it.

Yep code would help - maybe you are just using too much memory rather than it not being garbage collected quickly enough. I'm sure that if your process needs memory and some can be garbage collected then the runtime would do so rather than crashing. If however you actually try and use more memory than you have then this would be a problem. Maybe your code can be improved to work differently or use memory in a more efficient way?

IDisposable won't help

I wrote an article on IDisposable a few years ago: http://www.paxium.co.uk/PublicArticle/Article/497

Class Page
{
    List<Text> Texts;
    List<Image> Images;
    List<graphics> Graphics;
}

Text, Image and Graphics are other classes. Test and image have no other list within them but graphics have List<pathsegments> which in turn will have List<PathPoints>

Each time i am creating a object of Page class.

P.S: Sorry about the very delayed response.

If that is a true Image object in System.Drawing that right there can cause serious memory issues. I speak from experience as I have been trying to design my own Image Selector component (as I hate the one C# uses because I can't figure how to thread it).

Because of this I can work with tons and tons of images myself. This has led me to forcing myself to properly manage my resources, or manage them better. One was IDisposable, which I found a great article that finally explain it (sadly it's on my Desktop and not my work PC, so I'll have to get that to you later).

Now that being said, IDisposable works great for when you pretty much close out an object because if the code sees it's unused it will fire the Dispose event for you. However, from how I read what you are writing, you are still using these classes, and running into memory issues. My one suggestion, if you have Image objects you are using, dispose of them (they have a dispose class). Also if you are using temporary Images for say a resize, place the temp Image in a using statement, and when you want that value, clone it (like returning). I do this to preserve a lot of memory.

Here's a snippet of code I used for an Image Resizer

using (Image TempImage = new Bitmap((int) Math.Floor((double) MaxWidth), (int) Math.Floor((double) MaxHeight))) //creates a new image to the max size
{
    using (Graphics g = Graphics.FromImage(TempImage)) //resizes the image
    {
        g.InterpolationMode = InterpolationMode.HighQualityBicubic;
        g.PixelOffsetMode = PixelOffsetMode.HighQuality;
        g.DrawImage(value, 0, 0, ((int) Math.Floor(NewWidth)), ((int) Math.Floor(NewHeight)));
    }

    return (Image) TempImage.Clone();
}

Sorry if this is a little rushed have to get back to something soon. I'll try and return to this post when I get home tonight

Alright back, and hopefully a little more useful.

First of all here is the link for IDisposable I talked about. I highly suggest this, as it finally cleared it all up for me
http://manski.net/2012/01/idisposable-finalizer-and-suppressfinalize/

Now for your Image objects (again I assume that's a List of System.Drawing.Image items), here are a few tricks to remember.

First of all, Image objects pass by reference, unlike say a string or int. So if you are re-using an image over and over, load it in once and assign away with it (just make sure not to dispose of it or anything you passed it to). I do this for my code, I have a default image, that could easily be used over 100 times on a form. I load it in once, and assign it to each PictureBox.

Second, if you are done with an image, then Dispose of it. Images I have come to realize love to stick around. When working on my project, I have found that I have to keep a close eye on my Image objects. When I close a form for instance, I have a piece of code designed to index through all the PictureBox's on the form, and dispose of their Images. This help drastically control my memory issues.

Third, if it's a temporary image, place it in a using, Like the example I gave above. You can even do

using(Image image = Image.FromFile("FILENAME"))
{
    //do stuff with image
}

This using statement will also clean up the image when you are done with it. From how I understand, if it sees the code no longer has ties to it, it disposes of it.

Okay, I think that's a collection of tips I have. It's kind of hard to really offer much more as I don't fully see what you are trying to do with your objects and what not. One other thing to think of, would it be better to initialize/load an object at the time it's needed and dispose of it, or store it in memory? Sure you might take a small hit of performance, but it might help with the memory issue.

Oh yes and one more thing ... What exactly are you doing to blow an Out Of Memory? I have had programs that use over 1-3 GB of memory and run just fine. There is a side to me that wonders if maybe you should step back and possibly redesign it a little (the code that is)

Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.