Has anyone ever had a winform that used like 15-16 different collections? What was your memory usage?

We have a form with 15 collections (most are just small lookup collections with 5-25 entities) but the form (that has 5 tab pages, about 120 controls) uses 80-90 mbytes!! Is that normal?

Thnx.

Hmm... Are you sure the collections contain a small set of entities? If you're using selfservicing, code like: myCustomer.orders[index].OrderDetails[index2].someproperty will fetch all entities of that type for that particular parent entity and these will stay in memory until the parent entity is no longer used.

.NET winforms applications can eat a lot of memory. A simple hello world winforms app can take up to 19MB of mem, just 1 form and a single string.

All generated code is profiled with a profiler to check for memory leaks. You should take note however that you can create memory leaks yourself rather easily. Below is an explanation how this can happen.

Say you have a main form in which some entitycollections are stored. You create a subform and this subform binds to some events exposed by the collections or contained entities. Once you do that, the entity or the entity collection holds a reference to the form!. If you then close your form, the form will stay in memory, as it is still referenced (through the event handler) by the entity or entity collection objects which are also still in memory. If you're doing this a couple of times, your memory will be eaten away rather quickly.

Solution: remove any eventhandlers created when the form is unloaded. Please check if you do that.

Otis wrote:

If you're using selfservicing, code like:

No, we are using adapters. OK, I see that I was a bit imprecise. We use v1.0.2004.1 BETA LLBLGen, SQL Server, a lot of collections.

Otis wrote:

.NET winforms applications can eat a lot of memory. A simple hello world winforms app can take up to 19MB of mem, just 1 form and a single string.

We did a little test with memory usage and we got something like this: Just form: 13MB Form with adapter (created) and opened connection: 21MB Form with all our custom components (abot 120), a lot of declarations (a few entities in there): 26MB Form with 17 collections, 5 filled collections with fewer than 20 entities: 55MB Other collections are empty (just new keyword). And that is the smaller form with fewer filled collections. The other one uses about 80 MB (but has 12 filled collections with 5-30 entities). Everything is a debug build.

Another thing is that we have a large database with 120+ tables. The DAL dll uses about 3 MB disk space (if that is of any relevance).

Otis wrote:

Solution: remove any eventhandlers created when the form is unloaded. Please check if you do that.

Hmm.. i don't know if have that situation. I'll check. Since the application is tab based (a single form with a lot of tabs) I don't think that there is a situation like that!

Hmm... I'd seriously look at the custom properties, if these are in the entities or not. Some applications store big amounts of data in teh custom properties in the database and these are pulled into the entities if you're not careful. However this info is stored statically, so it should not show up per entity...

the data consumption is a little big... the thing is, not a lot of data is allocated by the collection classes or the entities. That is, if you're not having a lot of data in an entity.

Do you use grids?

If you do not bind the collections to the collections, you just load them from the db, is the memory consumption then also as high as you mention or is it much lower?

I will test the application with as few controls and as few collections as possible and see the results. Hopefully that will show where the largest memory usage is.

We do not use custom properties.

ivanc wrote:

I will test the application with as few controls and as few collections as possible and see the results. Hopefully that will show where the largest memory usage is.

We do not use custom properties.

Ok, please let me know if you need any help. Profiling memory usage can be hard. A thing I thought of was: do you keep the connection open of the adapter used? It's wise to close the connection and to dispose the adapter after each fetch if you don't need the connectoin in the same routine. The reason I thought about this was that an open connection can keep data locally in memory (the SqlConnection object), I don't know how much that is though...

I didn't have time to do some serious memory profiling, but we have come across a curious behavior... It seems that the LLBL objects indeed have a very small memory footprint. Databinding, controls and crappy garbage collector are responsible for huge memory usage.

If you minimize the application the memory is freed.

Example: Application starts (no DB connections, no entities... nothing): 3MB Open connection, load some collections (about 15), databind then: 40MB Minimize the application: 0.692 MB !!!! Maximize the app again: 11.8 MB Do some wild clicking and refetching: 18 MB Load a whole bunch of windows with additional collections and stuff: 35MB Minimize again: 0.748 MB Maximize: 7MB

If I do the same thing without minimizing... 90MB

What the hell is going on?

Wow... I've never done quicker and more pricise memory profiling in my life

Well, the window controls etc. all take a lot of memory which are freed when a window is minimized, because they're no longer used. A winforms form not only holds the win32 objects but also the .NET layer on top of it. When a form is minimized (it gets a native Win32 WM_ message) it apparently frees all objects referenced inside a form related to the gui. These are then restored when the window is restored.

It depends on the grid how many objects it embeds but this can be pretty complex and thus a huge amount of objects can be created.

So if our users complain about the memory usage we just have to say... Minimize and Maximize... cool. It's definitely better that Shutdown and Startup again. But what puzzles me is that after the window is maximized the memory usage is much lower than before and the same objects are displayed on the screen.

Does DevPartnerStudio work with C#?

Well, thanks anyway.

ivanc wrote:

So if our users complain about the memory usage we just have to say... Minimize and Maximize... cool. It's definitely better that Shutdown and Startup again. But what puzzles me is that after the window is maximized the memory usage is much lower than before and the same objects are displayed on the screen.

That's perhaps because everything is freed, also buffers which are not yet garbage collected ( I pressume).

However I'd be surprised if the user actually runs into out of memory messages... I mean, helloworld.cs with a textbox is sometimes over 10MB.

Does DevPartnerStudio work with C#?

What is DevPartnerStudio exactly?