Minimizing application memory footprint

[Bob Dufour]

We got a windows form application that we wrote in VB.Net.

Essentially its a manager for a list of persons and their contacts and some
other info about the persons. No rocket science but lots of textboxes and
comboxes to use lookup lists, some tab controls allow viewing of data about
a person in logical groupings.

We find that as we load the app with only a few hundred records of data in a
lookup list (Rough estimate of data only at this stage I say about 1400k)
the total app foot print at this stage is 47 megs.

First impression, that looks like an awfull lot for an application that has
one splash screen, one main form that is loaded in which there are about 200
controls, mostly textboxes, a bout 15 comboxes and a dozen or so
ComponentOne truedbgrids, each one with one or two Component One
trueDbDropDowns.

Second thing we see. When we pump the number of records up to 50000 we end
up with 127 Megs of RAM being used by this one app. We can pump the number
of loaded records up by having our code make a select for all 50000 records
and pumpt the number of loaded records down again by having our code select
only about 100 records marked as active. We're NOT talking about filtering
here. We clear and refill.

What I see when we pump the number of records down to 100 once we've
selected all, the meory footprint of the app remains at 127 megs. It does
not go down again.

Two questions if you would please.

1- Has anyone else noticed that apps in .Net seem to require substantially
bigger memory footprints that apps writen in previous versions of VB? Any
hard comparison info out there to conform or deny this impression.

2- Why would the memory footprint stay at its highest in the useage scenario
described above and more importantly, any ideas on how to efficiently
reclaim RAM. We implicitly close all objects when no longer in use so that
the garbage collector can do its job, but that does not seem to be enough.


Any comments or ideas on how to minimize applicatrion memory footprint would
be greatly appreciated.


BOB

 

[rawCoder]

Well a little point on your second question.
Minimize the app to see a drastic change in memory consumption.
I remember it was posted on teh newsgroup sometimes ago that the same effect
can be acheived through code by , i guess, letting GC reclaim mem.

HTH
rawCoder

 

[Imran Koradia]

First impression, that looks like an awfull lot for an application that

has
one splash screen, one main form that is loaded in which there are about
200
controls, mostly textboxes, a bout 15 comboxes and a dozen or so
ComponentOne truedbgrids, each one with one or two Component One
trueDbDropDowns.

IMHO, 200+ controls is still quite a bit for a single form.

Second thing we see. When we pump the number of records up to 50000 we end
up with 127 Megs of RAM being used by this one app. We can pump the number
of loaded records up by having our code make a select for all 50000
records
and pumpt the number of loaded records down again by having our code
select
only about 100 records marked as active. We're NOT talking about filtering
here. We clear and refill.

That's bound to happen if you're going to be loading 50,000 records all at
once. Obviously your client (or whoever is using the app) cannot see 50,000
all at once; you might want to try pulling records on demand - something
like what sql server enterprise manager does when displaying thousands of
records (assuming you have sql server; otherwise that would be a bad example
)

What I see when we pump the number of records down to 100 once we've
selected all, the meory footprint of the app remains at 127 megs. It does
not go down again.

Two questions if you would please.

1- Has anyone else noticed that apps in .Net seem to require substantially
bigger memory footprints that apps writen in previous versions of VB? Any
hard comparison info out there to conform or deny this impression.

The .NET CLR is loaded into the memory as well which is the reason why .NET
apps have a larger memory footprint as compared older VB apps. But I would
think that the memory difference gap becomes less of an issue for larger
applications which in general have a larger memory footprint since in that
case the memory utilized by the CLR would be a lower percent of that
utilized by the app (in most cases).

2- Why would the memory footprint stay at its highest in the useage
scenario
described above and more importantly, any ideas on how to efficiently
reclaim RAM. We implicitly close all objects when no longer in use so that
the garbage collector can do its job, but that does not seem to be enough.

Are you using any unmanaged resources such as database connections, etc?
call dispose (f they have one) on the objects that are utilizing these
resources since the GC is not aware of unmanaged memory usage and hence
cannot collect those resources which could potentially be one reason for a
larger memory footprint.

Any comments or ideas on how to minimize applicatrion memory footprint
would
be greatly appreciated.

Run the .NET profiler and see what's causing your app to use so much memory
and hold onto it.
Also, check out this link:
http://www.gotdotnet.com/team/clr/about_clr_performance.aspx
It has info on managed code performance and links to other performance
related stuff. That should give you some direction.


hope that helps..
Imran.

 

[Imran Koradia]

Well a little point on your second question.

Minimize the app to see a drastic change in memory consumption.
I remember it was posted on teh newsgroup sometimes ago that the same
effect
can be acheived through code by , i guess, letting GC reclaim mem.

yes - you *could* use the GC.Collect (or GC.Collect(generation) to collect a
particular generation) but its considered as a last resource to improve
memory usage. Here's a good explanation on this:
http://weblogs.asp.net/ricom/archive/2003/12/02/40780.aspx

Imran.

 

[Lucas Tam]

Second thing we see. When we pump the number of records up to 50000 we
end up with 127 Megs of RAM being used by this one app. We can pump
the number of loaded records up by having our code make a select for
all 50000 records and pumpt the number of loaded records down again by
having our code select only about 100 records marked as active. We're
NOT talking about filtering here. We clear and refill.

You're using a dataset aren't you?

 

[Bob Dufour]

We're usding C1 component datasets

You're using a dataset aren't you?

 

[Lucas Tam]

We're usding C1 component datasets

Datasets cache data in memory... so when you download 50,000 records, your
memory footprint will bloat.

You'll need to rethink your approach and reduce the use of datasets (C1 or
..NET).