Windows Develop Bookmark and Share   
 index > Windows Forms General > FolderBrowserDialog and Bitmap issue
 

FolderBrowserDialog and Bitmap issue

I spotted an issue about:

<!--[if !supportLists]-->FolderBrowserDialog;
<!--[if !supportLists]-->Bitmap;
<!--[if !supportLists]-->Garbage Collector.

The issue is done with Windows XP Pro v5.1 Service Pack 2, using Framework .Net 2.0. Source code is C#, developed in Visual Studio 2005.

ISSUE: In a managed project, using bitmap just after a FolderBrowserDialog disable the Garbage Collector.

METHODE: To reproduce this issue, do the following.

In a new WindowsApplication C# project, call the methode “IssueHere()�:

private void IssueHere()

{

using (FolderBrowserDialog fb = new FolderBrowserDialog())

{

if (fb.ShowDialog() == DialogResult.OK)

{

// Do nothing at all

}

}

for (int i = 0; i < 10000; i++)

{

Bitmap b = new Bitmap(@"C:\Image.bmp");

}

}

With the above code, look at your RAM commitment using a System Monitoring software. RAM memory increase until the program crash due to memory overhead. The Garbage Collector in this example doesn’t work.

Now, do this exercise for comparison:

private void NoIssueHere()

{

for (int i = 0; i < 10000; i++)

{

Bitmap b = new Bitmap(@"C:\Image.bmp");

}

}

Look again at your RAM monitor. The Garbage Collector clean correctly the memory when in need of room.

The only way I can avoid memory overhead using both FolderBrowserDialog and Bitmap is by creating a thread and process each other separately (each one in his own thread).

End of report. Feedback ?

G Mailhot  Thursday, September 27, 2007 9:26 PM
I cannot reproduce your problem. That's not unexpected, this depends critically on the state of the garbage collected heap and the exact contents of your bitmap. A Bitmap is a difficult object for the garbage collector. I takes a very small amount of space on the GC heap but lots of unmanaged memory. The garbage collector will only run when the generation 0 heap becomes full. Ten thousand Bitmap instances is not enough to fill it up. Which means you'll have ten thousand copies of the bitmap bits in unmanaged memory. You'll notice that.

The solution is simple and every .NET programmer should be aware of it. Use the Dispose() method to release unmanaged resources when you no longer need the bitmap. Change your loop to this:

for (int i = 0; i < 10000; i++)
{
Bitmap b = new Bitmap(@"C:\Image.bmp");
b.Dispose();
}

Look at the docs for the "using" keyword to get automatic Dispose() method calls.

nobugz  Friday, September 28, 2007 6:13 PM
I cannot reproduce your problem. That's not unexpected, this depends critically on the state of the garbage collected heap and the exact contents of your bitmap. A Bitmap is a difficult object for the garbage collector. I takes a very small amount of space on the GC heap but lots of unmanaged memory. The garbage collector will only run when the generation 0 heap becomes full. Ten thousand Bitmap instances is not enough to fill it up. Which means you'll have ten thousand copies of the bitmap bits in unmanaged memory. You'll notice that.

The solution is simple and every .NET programmer should be aware of it. Use the Dispose() method to release unmanaged resources when you no longer need the bitmap. Change your loop to this:

for (int i = 0; i < 10000; i++)
{
Bitmap b = new Bitmap(@"C:\Image.bmp");
b.Dispose();
}

Look at the docs for the "using" keyword to get automatic Dispose() method calls.

nobugz  Friday, September 28, 2007 6:13 PM

You can use google to search for other answers

Custom Search

More Threads

• Timer Residual WM_TIMER
• Visual Inheritance problem with FlowLayoutPanel Control
• The process cannot access the file 'myfile.html' because it is being used by another process.
• graphics path isoutlinevisible problem+C#
• webbrowser control issue
• OnMouseOver problems
• Highlighting row in DataGrid
• check box treeview
• ToolStripSplitButton BackColor does not work.
• Group Box and Panel Secrets Wanted