C# Class Instantiation Overflow

Question

Scenario

I have a C# Win Forms App, where the Main Form contains a loop that creates 3000 Instances of another CLASS (CLASS B). Inside Form B there are a large number of properties and fields and a bunch of methods that do a fair amount of processing.

Question

Will the creation of 3000 of these classes give me problems? I'm thinking along the lines of memory exceptions? I've had 1 or 2 already, and I've also had an exception that says something along the lines of "Something went bang and this is usually a sign of corrupt memory somewhere else".

Setup

I'm using a DevExpress Ribbon Form and I haven't implemented Dispose on anything....Do I need to?

Help greatly appreciated.

EDIT - I never meant to say 3000 FORMS.....I meant to say I have a single form that creates 3000 instances of another class.....

Answer 1

try to run your application using Memory Profilers and see where memory leak happening..

http://memprofiler.com/

Answer 2

You need to read this article. You will run out of window handles and you do need to implement and call dispose, but as the article states if you have to ask about this you are doing something wrong.

Each control in Windows Forms gets a unique window handle. As the article points out each process gets 10000 handles. Handles are released by calling dispose so you need to make sure your forms call dispose on their child controls. Most container controls take care of that part for you, but double check. Remember it is each control, text boxes everything.

I hit this once before. We had very complex forms that would get closed as the user was done with them, but we did not dispose of them properly. We hit the handle limit in a hurry. It also lead us to re-think the amount of information a user can really mentally process at one time and we simplified the forms.

It was our automated acceptance tests that caught us. They went through the forms faster than a user and hit the handle limit in a hurry.

EDIT In response to the change in the question

Well if it isn't 3000 forms you should be fine. You should still read the link, it's a good thing to know. But 3000 instances isn't much at all. Even if they each have 1000's of properties you should be just fine. As a simple check you can watch the application in task manager to make sure it's okay.

In general you need to implement IDisposable and call it if your classes have references to things like window handles, files, database connections etc. I don't know what your 3000 instances are doing so I can't tell you if you need IDisposable in this case.

Answer 3

3000 objects is not massive in general, but would have to question the sanity of 3000 forms.

Presumably you are not displaying these all to the user simultaneously so a better approach might be to open instances of the form as required by the user and have a method DisplayData(..) that populates the form with the data required for that record. A user is unlikely to open 3000 simutaneously! 3-5 would be more reasonable.

You should also think about re-layering your app so the processing logic is separated from the forms themselves. This will give you more flexibility for scaling the processing layer should you need to. Have a google for MVC / MVP as a starter.

Answer 4

I would recommend considering the flyweight pattern: http://en.wikipedia.org/wiki/Flyweight_pattern This is specifically designed to handle situations where you would normally be creating large amounts of objects and instead dynamically creates instances when they are actually needed.
An example of a flyweight would be to use a collection class, such as a dictionary to store all the properties that your objects that need to be persisted and when you need to interact with a specific object the flyweight pulls out the properties and creates the object dynamically, once finished with the properties are stored back in the collection and the object reference released.