"Surain Shen" <looong.shin (AT) gmail (DOT) com> wrote

It's important to understand the role of the GC, the GC is not a memory allocator, it's a
private heap manager, it controls and manages the "managed" object allocations by
collecting and compacting the generational heap(s), but the heap "segments" allocated from
the process heap are not under control of the GC, this is the task of the CLR's memory
allocator.
Without going too much in detail here is what happens, at the start, the CLR (memory
allocator) reserves two segments for the GC heaps (one for gen0, 1 , 2 and one for the Large
Object heap) from the OS, both of these segments are 16MB in size for the WKST version of
the CLR and two times 32 MB for the server version.
When a new object allocation hits a guard page in it's current segment, the GC will force a
collect/compactation run, and if after this run, the object allocation still hits the guard
page, then will the GC request the CLR for more memory, and the CLR memory manager will
request the OS for another segment of 16 or 32 MB. The GC can continue to allocate objects
from this new heap segment.
If after this, it happens that all objects are moved back to the initial segments after a GC
compactation run, the memory allocator is free to return that segment to the OS. Whether
this happens depends on a number of heuristics, like memory pressure GC type and object
allocation/de-allocation frequency, in general the memory allocator does return the excess
segments unless it is requested by the OS memory manager, or when a memory threashold is
reached.

Willy.

Hi, Willy,

Thx a lot for ur reply, I do think it hits my question well

There is a further question, but first pls have a glance at my story:

I had a winform app which consume much more memory than a similar app of
the competitor which looks written by VC. Compare the "VM Size" and "Mem
Usage" measure value in the task manager, my app always be twice over the
competitor's. As a result, the customer ask us to try decrease the memory
usage to a reasonable range, otherwise ...

I had tried to do somethings such as releasing the reference, disposing,
and I even find anonymous method will increase memory usage a bit, and
etc., but it seems the memory usage only decrease a little...

Ok, my final question is how can I decrease the memory usage obviously?
Of course, I and my customer known that .Net app will consume more memory
than the similar app which written by VC. We still hope to improve that
problem.

In addition, the VM Size of the .Net app and the VC app are about
120m/60m, and we hope to cut it down to 90m.

Best regards,

Surain Shen

"Willy Denoyette [MVP]" <willy.denoyette (AT) telenet (DOT) be> wrote in
news:ub#KMpEMHHA.3952 (AT) TK2MSFTNGP02 (DOT) phx.gbl:

"Surain Shen" <looong.shin (AT) gmail (DOT) com> wrote

Ask, the customer to remove some RAM from it's boxes, seriously why does an end user cares
about this?
Managed applications have a slightly larger memory footprint than comparable unmanaged
applications, the reason is the size of the CLR, it's managed heap and the size of the
loaded FCL (especially Windows Forms). This is something you can't get around, you need to
accept this, the larger footprint (because of the GC and the large heap) has numerous
advantages, the CLR makes better use of the available memory resources, so does the FCL
offer a rich set of API's, that means that you can build real complex applications in
managed code that don't consume much more (say the difference won't be larger than 10Mb)
memory space than a comparable native application, you get what you paid for, really.

Why, would you even try to do this, the OS will do it when there is a need for memory by
other applications.

language, it's up to you to watch your allocation algorithm and watch out for
over-consumption. Watch out for some OO designs, they tend to be the cause of
over-consumption, take care about Arrays and ArrayLists or container classes using Arrays as
backing store (or generic containers), don't use self expanding containers, pre-allocate
Arrays and List's whenever you can (you can most of the time). Otherwise stated, measure and
measure again. Use the CLR or another profiler, watch your allocation patterns, make sure
you apply a "dispose "pattern when needed, take special care about unmanaged code calls and
unmanaged memory resource usage. But keep in mind that you won't get (you don't need to) at
the level of unmanaged code, tell your customer that a similar application written in
assembly will probably use even less memory than the C equivalent, but it's price will be a
tenfold.



Willy.