Hi,
I've got an application, which has the following performance counters:
..NET CLR Memory\# Total committed Bytes = 12 MB
..NET CLR Memory\# Bytes in all heaps = 2,5 MB.
This means, that about 10 MB of memory is not used, but allocated.

Due to memory limitations I would like to let the managed heap be compacted
(e.g. by calling GC.Collect() and ???.ReleaseUnnecessayMemory()).
Is this possible?

Thx
Frank

Hi Frank

There a several reasons why there may be allocated unused memory. Pinned objects, for example, prevent the GC from compacting (even if you don't pin yourself, there are
some framework classes that do). Also, in v1.0 and v1.1 the large memory heap does not get compacted, since for performance reasons.

The GC will compact the heap when it performs a collection. I would recommend you let the GC compact when it deems it necessay, and not call GC.Collect() yourself.

Hope that helps
-Chris

--------------------


--

This posting is provided "AS IS" with no warranties, and confers no rights. Use of included script samples are subject to the terms specified at
http://www.microsoft.com/info/cpyright.htm

Note: For the benefit of the community-at-large, all responses to this message are best directed to the newsgroup/thread from which they originated.

How does the large object heap work in v 2.0? Is there any change?

--
Sriram Krishnan

http://www.dotnetjunkies.com/weblog/sriram


""Chris Lyon [MSFT]"" <clyon (AT) online (DOT) microsoft.com> wrote

Hi Chris,
thanks for this information.
In my program there are no pinned objects (according to perfmon).
The large object heap has a size of 1,3 MB.

Even a manual GC.Collect() just reduces the "Bytes in all heaps", but not
the "Total commited bytes".
The latter one is critical for me, because it directly affects the private
bytes (at least I assume this), which are critical for me.

Is there any chance to reduce the commited memory used by the CLR?

Thanks
Frank

""Chris Lyon [MSFT]"" <clyon (AT) online (DOT) microsoft.com> wrote

yourself, there are
GC.Collect() yourself.
originated.

Hi Sriram

There have been numerous improvements to the performance of the LOH, but as far as I know, nothing that involves .NET developers having to change their v1.0 or v1.1 apps.

-Chris

--------------------


--

This posting is provided "AS IS" with no warranties, and confers no rights. Use of included script samples are subject to the terms specified at
http://www.microsoft.com/info/cpyright.htm

Note: For the benefit of the community-at-large, all responses to this message are best directed to the newsgroup/thread from which they originated.

Hi Frank

For performance reasons, the large object heap does not contract, meaning if you allocated a 100MB of large objects, then the LOH will be at least 100MB, and not shrink. This
is because the GC bases its behaviour on your previous memory allocation patterns. If you allocated large memory in the past, it's cheaper to leave that amount reserved for
future allocations.

If this behaviour is causing your application problems, consider ways to avoid large memory allocaltions, for example, replace large arrays with ArrayLists, or consider pooling.

Hope that helps
-Chris

--------------------

--

This posting is provided "AS IS" with no warranties, and confers no rights. Use of included script samples are subject to the terms specified at
http://www.microsoft.com/info/cpyright.htm

Note: For the benefit of the community-at-large, all responses to this message are best directed to the newsgroup/thread from which they originated.

Yes - I just want to know whether there's anything you can tell us about
what those improvements are. I'm impatient and don't really want to wait for
Rotor v2. So if there's any publically available info, please point us to
it

--
Sriram Krishnan

http://www.dotnetjunkies.com/weblog/sriram


""Chris Lyon [MSFT]"" <clyon (AT) online (DOT) microsoft.com> wrote

There is nothing I can specifically comment on at this time. Sorry!

-Chris

--------------------

--

This posting is provided "AS IS" with no warranties, and confers no rights. Use of included script samples are subject to the terms specified at
http://www.microsoft.com/info/cpyright.htm

Note: For the benefit of the community-at-large, all responses to this message are best directed to the newsgroup/thread from which they originated.