huge memory useage

[Vasil Buraliev]

Hallo. I started a solution in VS.NET with template for C# windwos
application. The solution has several projects:
-Artifacts
-BusinessRules
-Client
-ErrorLog
-Standardization
....
...
..
When application is stared you can see only one form with 4 userControls
included on it. Each user control contains:
- toolbas user control : 4 combo controls + 2 buttons
- image user control: kodak image edit control + 6 buttons
- data entry user control: 3 listviewz, 10 buttons, 6 edit controls, 1 combo
- view list control: 1 list view control
and few buttons on form

I don't use unmanaged variables in appilcation so I expect GC to do work for
me and take care about destroing the objects.
When I start that exe assembly I got process in memory for this application
~32MB.
Is this memory usage for this kind of application normal!? For me it's looks
like too much memory. When I load image in kodak control process grows to
~45MB.
Where I'm wrong!? I don't think that tis useage of memory is normal even for
..NET app.
When I minimize app process gets unbelivable 600KB of memory useage. What's
going on!?

Would you help me please and tell me how to limit this 45MB to something
smaller and how to use GC when I use only managed variables!? Should I
derive all Artifacts, Businessruless and Standardization classes from
IDisposable and override Dispose method for all classes which I will call
after I finished with some object from that classes?

regards
Vasko

[Jax]

Considering I have 2 IE instances running at 24,000K a piece, I dont think it's that unusual.

[Martin Maat [EBL]]

"Vasil Buraliev" <ph*****@mol.co m.mk> wrote in message
news:OX******** *****@tk2msftng p13.phx.gbl...

When I start that exe assembly I got process in memory for this application ~32MB.
Is this memory usage for this kind of application normal!? For me it's looks like too much memory.

Yes... Coming from the 64K RAM computer days this is pretty shameful.

It would be interesting to see the behavior on different machines with
diferent RAM sizes. It seems that the CLR just grabs a substantial amount of
the available RAM and then distributes that amount among the running managed
applications. This is not necessarily bad, it may be a performance
optimization. You could also try and start several versions of the same
application, you may see the memory used per application decrease.

I am only speculating though but it seems like a reasonable approach. The
CLR is, as far as memory management is concerned, an OS within the OS and
may assign resources to an app generously as long as they're not scarce. And
you don't have to be aware of the requests for memory going on, the form or
some control may be overasking in anticipation somewhere deep down in the
tree. The memory is waisted anyway if it isn't assigned to any process. I am
interested to read if there is any truth to my assumption.

Martin.

[Vasil Buraliev]

Hi Martin,
thank you for your idea.
I started 5 instance of Application and the memory was variate. Probably GC
did something. But in general the size of the application it was big. The
objects that I use in the applicatin and list of objects are preaty huge.
Anyhow... I think you will be interesting to read an descusion from
microsoft.publi c.dotnet.framew ork.performance with Subject: GC does not
release memory...memory keeps growing!!!!

regards
Vasko

"Martin Maat [EBL]" <du***@somewher e.nl> wrote in message
news:10******** *****@corp.supe rnews.com...

"Vasil Buraliev" <ph*****@mol.co m.mk> wrote in message
news:OX******** *****@tk2msftng p13.phx.gbl...

When I start that exe assembly I got process in memory for this application

~32MB.
Is this memory usage for this kind of application normal!? For me it's

looks

like too much memory.

Yes... Coming from the 64K RAM computer days this is pretty shameful.

It would be interesting to see the behavior on different machines with
diferent RAM sizes. It seems that the CLR just grabs a substantial amount

of the available RAM and then distributes that amount among the running managed applications. This is not necessarily bad, it may be a performance
optimization. You could also try and start several versions of the same
application, you may see the memory used per application decrease.

I am only speculating though but it seems like a reasonable approach. The
CLR is, as far as memory management is concerned, an OS within the OS and
may assign resources to an app generously as long as they're not scarce. And you don't have to be aware of the requests for memory going on, the form or some control may be overasking in anticipation somewhere deep down in the
tree. The memory is waisted anyway if it isn't assigned to any process. I am interested to read if there is any truth to my assumption.

Martin.

[Mark]

"Martin Maat [EBL]" <du***@somewher e.nl> wrote in
news:10******** *****@corp.supe rnews.com:

"Vasil Buraliev" <ph*****@mol.co m.mk> wrote in message
news:OX******** *****@tk2msftng p13.phx.gbl...

When I start that exe assembly I got process in memory for this
application ~32MB. Is this memory usage for this kind of application
normal!? For me it's looks like too much memory.

If you're using task manager to get your numbers, your numbers are wrong
(search for working set size to see the other millions of answers).
It seems that the CLR just grabs a substantial
amount of the available RAM and then distributes that amount among the
running managed applications.

No, no, no. Windows manages the WSS for a process. Doing it yourself will
almost certainly lead to poorer performance. There's a CLR loaded for each
managed application. What you're seeing is the initial cost of loading (JIT
et al) and then Windows leaving the WSS big (because you may need the
memory again in the future).

Mark

[Martin Maat [EBL]]

"Vasil Buraliev" <ph*****@mol.co m.mk> wrote in message
news:%2******** ********@TK2MSF TNGP12.phx.gbl. ..

I started 5 instance of Application and the memory was variate. Probably GC did something. But in general the size of the application it was big. The
objects that I use in the applicatin and list of objects are preaty huge.
Anyhow... I think you will be interesting to read an descusion from
microsoft.publi c.dotnet.framew ork.performance with Subject: GC does not
release memory...memory keeps growing!!!!

That was quite a thread. I learned the following that may apply in your
situation as well.

1. If you are encountering these problems you should try to re-use objects
if possible instead of recreating them. If objects are recreated all the
time and the GC doesn't instantly clean up after you for some reason you,
memory use is likely to grow needlessly. Also, if you are keeping references
without being aware of it, re-using the same object will prevent anything
more than that one object to remain. and use memory.

2. For certain types of object it is "behavior by design" to allocate chunks
of 64 MB. It seems odd to me as well but it seems to be somewhat normal and
Microsoft considers bringing it down to 16 MB "a fix":
"This hotfix adjusts the allocation size for the large
object heap segments from 64 megabytes (MB) per segment to 16 MB."
http://support.microsoft.com/default...b;en-us;833610

3. Task manager does not provide reliable information about managed
applications. I've seen different explanations on the matter and they
weren't all consistent but there seem to be some issues with it that may
give you the wrong idea so you should use performance counters instead.

4. Most of the troubled applications seem to use ADO.NET. This would be the
first think to suspect if I were to encounter these issues. There may be
some read-ahead logic or other anticipating sceme at work. Try the code
without referencing ADO.NET natspaces and see the difference.
Then I heard of some tool called FxCop. It analyses your code and gives you
pointers as to how your code could be optimized. It may catch some improper
construct that causes your problem.

http://msdn.microsoft.com/msdntv/epi...M/manifest.xml
http://www.gotdotnet.com/team/fxcop/

Martin.

[Vasil Buraliev]

Thank you Marting for yor useful information.
I will get FxCop and try to find which objects still and hold most of the
memory.

best regards.
Vasko

"Martin Maat [EBL]" <du***@somewher e.nl> wrote in message
news:10******** *****@corp.supe rnews.com...

"Vasil Buraliev" <ph*****@mol.co m.mk> wrote in message
news:%2******** ********@TK2MSF TNGP12.phx.gbl. ..

I started 5 instance of Application and the memory was variate. Probably GC

did something. But in general the size of the application it was big. The objects that I use in the applicatin and list of objects are preaty huge. Anyhow... I think you will be interesting to read an descusion from
microsoft.publi c.dotnet.framew ork.performance with Subject: GC does not
release memory...memory keeps growing!!!!

That was quite a thread. I learned the following that may apply in your
situation as well.

1. If you are encountering these problems you should try to re-use objects
if possible instead of recreating them. If objects are recreated all the
time and the GC doesn't instantly clean up after you for some reason you,
memory use is likely to grow needlessly. Also, if you are keeping

references without being aware of it, re-using the same object will prevent anything
more than that one object to remain. and use memory.

2. For certain types of object it is "behavior by design" to allocate chunks of 64 MB. It seems odd to me as well but it seems to be somewhat normal and Microsoft considers bringing it down to 16 MB "a fix":
"This hotfix adjusts the allocation size for the large
object heap segments from 64 megabytes (MB) per segment to 16 MB."
http://support.microsoft.com/default...b;en-us;833610

3. Task manager does not provide reliable information about managed
applications. I've seen different explanations on the matter and they
weren't all consistent but there seem to be some issues with it that may
give you the wrong idea so you should use performance counters instead.

4. Most of the troubled applications seem to use ADO.NET. This would be the first think to suspect if I were to encounter these issues. There may be
some read-ahead logic or other anticipating sceme at work. Try the code
without referencing ADO.NET natspaces and see the difference.
Then I heard of some tool called FxCop. It analyses your code and gives you pointers as to how your code could be optimized. It may catch some improper construct that causes your problem.

http://msdn.microsoft.com/msdntv/epi...20031204FxCopM
M/manifest.xml http://www.gotdotnet.com/team/fxcop/

Martin.

[Baskar]

Hi,

This is Baskar here.

I have explained our problem below, please read this and help us to get it done.

We are developing a statistical project.

Development environment specification is given below

Hardware :

· Pentium III with 256 MB Ram, 20 GB H.D

Software :

· Microsoft Windows 2000
· Microsoft .net
We are having around 50 Forms, 13 Classes and 17 Modules in out product. Out problem is if we run our application it is taking round 30 MB Memory, because of this clipboard function (cut, copy & paste) is not working in none of the application.
Please help us to solve this problem

Your immediate reply will help us to get it done as early as possible

Anticipating your reply

With regards

Baskar C.G


*************** *************** *************** *******
Ohkawa Mould Designs&Enginee ring Pvt Ltd
(SoftwareDivisi on)
#1521,39 F-Cross 4-T Block
JayaNagar Banglore INDIA
Ph:[phone]
Fx:[phone]
Email:oh*****@v snl.com
Visit us @ www.ohkawasoft.com
*************** *************** *************** ***