 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
.NET Forum / .NET Framework / Performance / October 2004compact managed heap
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 -------------------- >Hi, >I've got an application, which has the following performance counters: [quoted text clipped - 8 lines] >Thx >Frank  SignatureThis 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? SignatureSriram Krishnan http://www.dotnetjunkies.com/weblog/sriram > Hi Frank > [quoted text clipped - 26 lines] >>Thx >>Frank 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 -------------------- >How does the large object heap work in v 2.0? Is there any change? > [quoted text clipped - 28 lines] >>>Thx >>>Frank SignatureThis 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 SignatureSriram Krishnan http://www.dotnetjunkies.com/weblog/sriram > Hi Sriram > [quoted text clipped - 40 lines] >>>>Thx >>>>Frank There is nothing I can specifically comment on at this time. Sorry! -Chris -------------------- >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 [quoted text clipped - 45 lines] >>>>>Thx >>>>>Frank SignatureThis 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 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 > 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 [quoted text clipped - 13 lines] > >Thx > >Frank 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 -------------------- >Hi Chris, >thanks for this information. [quoted text clipped - 48 lines] >message are best directed to the newsgroup/thread from which they >originated. SignatureThis 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. Free MagazinesGet these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...
|
Reply to this Message
|
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2008 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.