High memory usage

  • Thread starter Thread starter Philip Carnstam
  • Start date Start date
P

Philip Carnstam

How come .Net applications use so much memory? Every application I compile
uses at least 10 MB of memory, even the ones consisting of only a form and
nothing else. If I minimize them though the memory usage drops to a couple
hundred KB. Why?

Is there anything I should to to prevent this? I have compiled in release
and deactivated all forms of debugging, I think!

Thanks,
Philip
 
Philip,

You could reduce the working set down to zero using API calls, but it
will just creep back up. The reason why the memory is consumed is because
the runtime is using the memory for garbage collection.

Hope this helps.
 
Hi,
You could reduce the working set down to zero using API calls,
but it will just creep back up. The reason why the memory is
consumed is because the runtime is using the memory for garbage
collection.

..NET is quite greedy with memory.. but it does play fair. When you have lots
of memory available it will allocate lots, when there is very little it will
release what it doesn't need (like when you minimise the app).

There's a demo in one of the TechEd 2003 speeches available online (I forget
the address).

-- Pete
 
See inline ****

Pete said:
.NET is quite greedy with memory.. but it does play fair. When you have lots
of memory available it will allocate lots, when there is very little it will
release what it doesn't need (like when you minimise the app).

**** Too much honor for the CLR, actually it's the OS who (tries to) reclaims the memory (trimming the WS) :-).
There's a demo in one of the TechEd 2003 speeches available online (I forget
the address).

-- Pete


Willy.
 
Is'nt there any way of solving this?
Non DotNet applications are able to run on very low memory usage... There
must be a way to lower the memory "costs" of running a DotNet application.

The whole DotNet idea is ridiculous otherwise... Can I only have 10 home
made DotNet applications active at once on a 128 MB Ram machine before the
machine completely runs out of memory?
Sounds mighty strange to me...

Thankful for any answers I can get!

Nicholas Paldino said:
Philip,

You could reduce the working set down to zero using API calls, but it
will just creep back up. The reason why the memory is consumed is because
the runtime is using the memory for garbage collection.

Hope this helps.


--
- Nicholas Paldino [.NET/C# MVP]
- (e-mail address removed)

Philip Carnstam said:
How come .Net applications use so much memory? Every application I compile
uses at least 10 MB of memory, even the ones consisting of only a form and
nothing else. If I minimize them though the memory usage drops to a couple
hundred KB. Why?

Is there anything I should to to prevent this? I have compiled in release
and deactivated all forms of debugging, I think!

Thanks,
Philip
 
I was under the impression that the working set was the physical memory
usage of the application...

When you minimise the application, dosnt that kick on the OS to page the
memory to harddisk..

I did a test sometime back.. I created a huge array and filled it with
random garbage. Then told it to wait for a key press. I minimised the page
and opened it up again and checked its memory usage. The memory usage by
the app was not enough to hold the array of garbage i stored in the array.
Then i pressed a key and the memory usage jumped up while it was outputting
the garbage back to the screeen. This to me indicates that when i minimised
it, the app had written it to disk reducing the working set. When i started
it back up again, the data was retrieved from disk and output to screen...

Cheers
HappyH

Philip Carnstam said:
Is'nt there any way of solving this?
Non DotNet applications are able to run on very low memory usage... There
must be a way to lower the memory "costs" of running a DotNet application.

The whole DotNet idea is ridiculous otherwise... Can I only have 10 home
made DotNet applications active at once on a 128 MB Ram machine before the
machine completely runs out of memory?
Sounds mighty strange to me...

Thankful for any answers I can get!

in message news:[email protected]...
Philip,

You could reduce the working set down to zero using API calls, but it
will just creep back up. The reason why the memory is consumed is because
the runtime is using the memory for garbage collection.

Hope this helps.


--
- Nicholas Paldino [.NET/C# MVP]
- (e-mail address removed)

Philip Carnstam said:
How come .Net applications use so much memory? Every application I compile
uses at least 10 MB of memory, even the ones consisting of only a form and
nothing else. If I minimize them though the memory usage drops to a couple
hundred KB. Why?

Is there anything I should to to prevent this? I have compiled in release
and deactivated all forms of debugging, I think!

Thanks,
Philip
 
That's all great, but what about other apps while I have the DotNet app up?
I find it very, very strange that an application consisting of nothing but
an empty form would use 10 MB of memory...
Take for example Solitaire, it uses 3 MB of memory while viewed, it simply
can't be that DotNet applications would use 3x more memory than that even
though they do not do anything... If so, DotNet applications are worthless
on all but computers with memory availibility beyond 512MB.


happyH said:
I was under the impression that the working set was the physical memory
usage of the application...

When you minimise the application, dosnt that kick on the OS to page the
memory to harddisk..

I did a test sometime back.. I created a huge array and filled it with
random garbage. Then told it to wait for a key press. I minimised the page
and opened it up again and checked its memory usage. The memory usage by
the app was not enough to hold the array of garbage i stored in the array.
Then i pressed a key and the memory usage jumped up while it was outputting
the garbage back to the screeen. This to me indicates that when i minimised
it, the app had written it to disk reducing the working set. When i started
it back up again, the data was retrieved from disk and output to screen...

Cheers
HappyH

Philip Carnstam said:
Is'nt there any way of solving this?
Non DotNet applications are able to run on very low memory usage... There
must be a way to lower the memory "costs" of running a DotNet application.

The whole DotNet idea is ridiculous otherwise... Can I only have 10 home
made DotNet applications active at once on a 128 MB Ram machine before the
machine completely runs out of memory?
Sounds mighty strange to me...

Thankful for any answers I can get!

in message news:[email protected]...
Philip,

You could reduce the working set down to zero using API calls, but it
will just creep back up. The reason why the memory is consumed is because
the runtime is using the memory for garbage collection.

Hope this helps.


--
- Nicholas Paldino [.NET/C# MVP]
- (e-mail address removed)

How come .Net applications use so much memory? Every application I compile
uses at least 10 MB of memory, even the ones consisting of only a
form
and
nothing else. If I minimize them though the memory usage drops to a couple
hundred KB. Why?

Is there anything I should to to prevent this? I have compiled in release
and deactivated all forms of debugging, I think!

Thanks,
Philip
 
Hi,

Philip said:
The whole DotNet idea is ridiculous otherwise... Can I only have 10
home made DotNet applications active at once on a 128 MB Ram machine
before the machine completely runs out of memory?
Sounds mighty strange to me...

There are two things to consider here:

1) In low memory conditions your application will use less memory (try
opening many high memory usage applications and see for yourself). You get a
similar effect when you application is minimised and restored.

2) Most of that memory usage is the framework itself.. which *should* be
shared between applications running at the same time (someone correct me if
I'm wrong with this). If I'm right on this, having many .NET apps open at
once should take less memory than having many (similar) non-.net apps open.

Basically ignore what the task manager is telling you and just write your
program.

-- Pete
 
Each program has to load the CLR runtime, the Jitter, the C runtime library and some Win32 libraries, most of these are SHARED
libraries. The CLR also reserves memory for the GC heap
Your minimal application also has to load mscorlib and the windows.forms package.
90% of this 10 MB has been taken by these libs. So a much larger application will not take much more memory unless you are creating
a lot of (or large) objects.

Willy.

Philip Carnstam said:
That's all great, but what about other apps while I have the DotNet app up?
I find it very, very strange that an application consisting of nothing but
an empty form would use 10 MB of memory...
Take for example Solitaire, it uses 3 MB of memory while viewed, it simply
can't be that DotNet applications would use 3x more memory than that even
though they do not do anything... If so, DotNet applications are worthless
on all but computers with memory availibility beyond 512MB.


happyH said:
I was under the impression that the working set was the physical memory
usage of the application...

When you minimise the application, dosnt that kick on the OS to page the
memory to harddisk..

I did a test sometime back.. I created a huge array and filled it with
random garbage. Then told it to wait for a key press. I minimised the page
and opened it up again and checked its memory usage. The memory usage by
the app was not enough to hold the array of garbage i stored in the array.
Then i pressed a key and the memory usage jumped up while it was outputting
the garbage back to the screeen. This to me indicates that when i minimised
it, the app had written it to disk reducing the working set. When i started
it back up again, the data was retrieved from disk and output to screen...

Cheers
HappyH

Philip Carnstam said:
Is'nt there any way of solving this?
Non DotNet applications are able to run on very low memory usage... There
must be a way to lower the memory "costs" of running a DotNet application.

The whole DotNet idea is ridiculous otherwise... Can I only have 10 home
made DotNet applications active at once on a 128 MB Ram machine before the
machine completely runs out of memory?
Sounds mighty strange to me...

Thankful for any answers I can get!

in message Philip,

You could reduce the working set down to zero using API calls, but it
will just creep back up. The reason why the memory is consumed is because
the runtime is using the memory for garbage collection.

Hope this helps.


--
- Nicholas Paldino [.NET/C# MVP]
- (e-mail address removed)

How come .Net applications use so much memory? Every application I
compile
uses at least 10 MB of memory, even the ones consisting of only a form
and
nothing else. If I minimize them though the memory usage drops to a
couple
hundred KB. Why?

Is there anything I should to to prevent this? I have compiled in
release
and deactivated all forms of debugging, I think!

Thanks,
Philip
 
Pete,
Philip said:
The whole DotNet idea is ridiculous otherwise... Can I only have 10
home made DotNet applications active at once on a 128 MB Ram machine
before the machine completely runs out of memory?
Sounds mighty strange to me...
[snip]

Basically ignore what the task manager is telling you and just write your
program.

By-the-way --> The task manager does lie at times about the memory
consumption. It can not be trusted to give the exact information all the
time.

Regards,

Randy
 
Philip Carnstam said:
If so, DotNet applications are worthless
on all but computers with memory availibility beyond 512MB.

If you like your apps lean and quick, I doubt DotNet is
the tool you want to use at this point of its evolution.

look at C, C++, Delphi...

The Next Big Thing isn't the always the right hammer for every nail.
 
Willy Denoyette said:
See inline ****



**** Too much honor for the CLR, actually it's the OS who
(tries to) reclaims the memory (trimming the WS) :-).

Well, it's not *just* the OS here. The CLR responds to memory
requirements of other apps by garbage collecting appropriately (when it
might not bother if there's plenty of memory available).
 
The problem is that DotNet does do alot of the things I want the application
to do easily, for example, being able to use xml documents as data
sources... I only find it strange that the memory usage is so high, but I
guess I'm stuck with that fact...

Thanks for all the response!
 
In addition to what everyone else said, here's an example of just how
many files are loaded into memory. It's a simple little WinForm to
get the MD5 checksum. The files that are loaded are:

c:\winnt\system32\MPR.DLL
c:\winnt\system32\ADVAPI32.DLL
c:\winnt\system32\KERNEL32.DLL
c:\winnt\system32\MSCOREE.DLL
c:\winnt\system32\NTDLL.DLL
c:\winnt\system32\RPCRT4.DLL
c:\winnt\system32\ACTIVEDS.DLL
c:\winnt\system32\ADSLDPC.DLL
c:\winnt\system32\CABINET.DLL
c:\winnt\system32\COMCTL32.DLL
c:\winnt\system32\COMDLG32.DLL
c:\winnt\system32\CRYPT32.DLL
c:\winnt\system32\DBGHELP.DLL
c:\winnt\system32\DNSAPI.DLL
c:\winnt\system32\GDI32.DLL
c:\winnt\system32\IMAGEHLP.DLL
c:\winnt\system32\LZ32.DLL
c:\winnt\system32\MLANG.DLL
c:\winnt\system32\MSASN1.DLL
c:\winnt\system32\MSI.DLL
c:\winnt\system32\MSVCRT.DLL
c:\winnt\system32\NETAPI32.DLL
c:\winnt\system32\NETRAP.DLL
c:\winnt\system32\NTDSAPI.DLL
c:\winnt\system32\OLE32.DLL
c:\winnt\system32\OLEAUT32.DLL
c:\winnt\system32\SAMLIB.DLL
c:\winnt\system32\SECUR32.DLL
c:\winnt\system32\SETUPAPI.DLL
c:\winnt\system32\SFC.DLL
c:\winnt\system32\SFCFILES.DLL
c:\winnt\system32\SHELL32.DLL
c:\winnt\system32\SHLWAPI.DLL
c:\winnt\system32\TAPI32.DLL
c:\winnt\system32\URLMON.DLL
c:\winnt\system32\USER32.DLL
c:\winnt\system32\USERENV.DLL
c:\winnt\system32\VERSION.DLL
c:\winnt\system32\W32TOPL.DLL
c:\winnt\system32\WININET.DLL
c:\winnt\system32\WINMM.DLL
c:\winnt\system32\WINSPOOL.DRV
c:\winnt\system32\WINTRUST.DLL
c:\winnt\system32\WLDAP32.DLL
c:\winnt\system32\WS2_32.DLL
c:\winnt\system32\WS2HELP.DLL
c:\winnt\system32\WSOCK32.DLL

Austin Ehlers
 
Jon,

While it's possible for the CLR to return virtual memory to the OS (Commited or reserved) by calling VirtualFree I never saw he did
under memory pressure. The only thing I see is that the OS trims the WS by returning unused (unaccessed) pages to swap file when
there is ample memory.
As to your remark "The CLR responds to memory requirements of other apps", how do you think the CLR knows about memory requirements
of other app's?

Willy.
 
See inline ****
Willy.

Pete said:
Hi,



There are two things to consider here:

1) In low memory conditions your application will use less memory (try
opening many high memory usage applications and see for yourself). You get a
similar effect when you application is minimised and restored.
**** Note that minimizing app's only results in trimming of the WS, that is pages are returned to the paging file, or are simply
freed when read-only pages.
2) Most of that memory usage is the framework itself.. which *should* be
shared between applications running at the same time (someone correct me if
I'm wrong with this). If I'm right on this, having many .NET apps open at
once should take less memory than having many (similar) non-.net apps open.
**** You are (unfortunately) wrong here, FCL (Jitted) code is non-shared, only a part is shared code (the native code DLL's).
 
Willy Denoyette said:
While it's possible for the CLR to return virtual memory to the
OS (Commited or reserved) by calling VirtualFree I never saw he did
under memory pressure. The only thing I see is that the OS trims the
WS by returning unused (unaccessed) pages to swap file when
there is ample memory. As to your remark "The CLR responds to memory
requirements of other apps", how do you think the CLR knows about
memory requirements of other app's?

I don't know the details of how it does it, but it definitely responds
to memory pressure. A while ago in the framework group someone was
asking about a program which crashed when there was still garbage
available to be collected. When two of the programs were run at the
same time, however, the runtime noticed that there was memory pressure
and ran the garbage collector more often.

I know I read about it somewhere, but I can't for the life of me find
the article now... it could be that I was misinterpreting things, of
course.
 
Hi,
**** Note that minimizing app's only results in trimming of the WS,
that is pages are returned to the paging file, or are simply freed
when read-only pages.

Is there a difference that matters?
**** You are (unfortunately) wrong here, FCL (Jitted) code is
non-shared, only a part is shared code (the native code DLL's).

Are you sure? Memory usage for the first .NET app I open appears to be
around 8 meg (watching freeram xp pro's system memory monitor drop), whereas
the second app open at the same time uses only 3. It's the same in reverse
(8 then 3). Under task manager both are shown to use roughly 11MB of memory.
Surely such a discrepancy cannot be entirely the native DLL's?

This is still true.

-- Pete
 
Pete,
See inline ****

Willy.

Pete said:
Hi,


Is there a difference that matters?

*** Yes, note that we are talking about virtual memory, that is the total of real RAM and page file space. When trimming the WS, RW
pages are moved from memory to the paging file, this does not necessarily reduce the VM size of the process, the net result is a
performance drop due to disk I/O when paging (in/out).
Are you sure? Memory usage for the first .NET app I open appears to be
around 8 meg (watching freeram xp pro's system memory monitor drop), whereas
the second app open at the same time uses only 3. It's the same in reverse
(8 then 3). Under task manager both are shown to use roughly 11MB of memory.
Surely such a discrepancy cannot be entirely the native DLL's?

*** If you look at a non NGEN'ed managed application, the shared pages are filled with:

- The C runtime library (msvcr.dll, msvcrxx.dll)
- The CLR (mscoree.dll, mscorwks.dll (or mscorsvr.dll) and mscorlib.dll, mscorjit.dll)
- Native kernel modules (Advapi32.dll, kernel32.dll, user32.dll, gdi32.dll, shell32.dll, etc......)
- COM (rpcrt4.dll, ole32.dll, oleaut.dll)
This part accounts for a large amount reserved RO/ RW memory (RO part can be shared amongst all other processes managed/unmanaged).
The amount depends on the number of pages already loaded by other (unmanaged/managed processes.
When you start another instance (or any other managed application) only part of the shared code has to be mapped, resulting in a
smaller memory footprint (virtually !).

Managed code however, is stored in private pages when Jitted and can as such not be shared. The result is a larger WS for managed
code compared to non managed code.
 
I have a much worse problem. The memory usage of my .Net application keeps
climbing up, eventually the application will crash with an "Out Of Memory"
error. At that point, the page file size reached 1.45GB. The action of
minimizing the form will make the Mem Usage drop from hundreds of MB to a
few MB, but the VM remains the same huge number and keeps increasing, and
the Mem Usage will climb back even with the form minimized.

Any idea how to debug a memory leak in C# .Net applications? My aplication
creates thousands of small objects in local scope, most of them strings. I
expect the GC would free the memory once the objects are out of scope, but
it seems our garbage man cannot sweep fast enough.

Angie
 
Back
Top