GC and memory
-
After creating a lot of objects and then freeing them in my code and calling
GC.Collect(2)the memory footprint does not go back to the pre allocation point in the app. Using a tool called VMMap (great tool by the way!) it show that the memory is in the GC's hands (out of the application's). Is there a way to get around this?A programmer walks into a bar and asks the bartender for 1.00000000000003123939 root beers. Bartender says, I'll have to charge you extra, that's a root beer float. Programmer says, better make it a double then.
-
After creating a lot of objects and then freeing them in my code and calling
GC.Collect(2)the memory footprint does not go back to the pre allocation point in the app. Using a tool called VMMap (great tool by the way!) it show that the memory is in the GC's hands (out of the application's). Is there a way to get around this?A programmer walks into a bar and asks the bartender for 1.00000000000003123939 root beers. Bartender says, I'll have to charge you extra, that's a root beer float. Programmer says, better make it a double then.
I think it is implementation-specific. The VM doesn't explicitly call free() on those objects. Instead, it caches the memory for further reuse in order to cope with malloc() overheads. But, if I leave my app idle for a while, the memory is slowly released. Same thing is also observed in Oracle's Java VM for windows.
Beauty cannot be defined by abscissas and ordinates; neither are circles and ellipses created by their geometrical formulas.
-
After creating a lot of objects and then freeing them in my code and calling
GC.Collect(2)the memory footprint does not go back to the pre allocation point in the app. Using a tool called VMMap (great tool by the way!) it show that the memory is in the GC's hands (out of the application's). Is there a way to get around this?A programmer walks into a bar and asks the bartender for 1.00000000000003123939 root beers. Bartender says, I'll have to charge you extra, that's a root beer float. Programmer says, better make it a double then.
Task Manager is showing you the memory the the .NET CLR has RESERVED for your application, not how much it's actually using. The same goes for VMMAP. Neither tool goes into any of the details of the managed runtime memory manager. If you want to see how much memory your app is really using at any point in time, open PerfMon and use the .NET Memory counters in there. The memory that your application uses, when freed, gets returned to the Managed Heap in the .NET CLR, not to Windows. This is because allocations for future objects are faster is there is memory available in the managed heap. If not, then a block of memory has to be allocated from Windows, put in the managed heap, then your object allocated. This takes more time. Unless you're really worried about how much memory your app is actually using, you're worried about nothing. The .NET CLR memory manager is very good at it's job and tunes itself depending on how your app is running. It's constantly watching how your app allocates and frees memory and adjusts the size of the managed heap every once in a while. But, if Windows needs the memory back, the .NET CLR will happily return any memory it can to Windows.
A guide to posting questions on CodeProject[^]
Dave Kreskowiak -
After creating a lot of objects and then freeing them in my code and calling
GC.Collect(2)the memory footprint does not go back to the pre allocation point in the app. Using a tool called VMMap (great tool by the way!) it show that the memory is in the GC's hands (out of the application's). Is there a way to get around this?A programmer walks into a bar and asks the bartender for 1.00000000000003123939 root beers. Bartender says, I'll have to charge you extra, that's a root beer float. Programmer says, better make it a double then.
GC.WaitForPendingFinalizersmay help. I needed it in some cases, when I experieced OutOfMemory exceptions despite calling GC.Collect. -
Task Manager is showing you the memory the the .NET CLR has RESERVED for your application, not how much it's actually using. The same goes for VMMAP. Neither tool goes into any of the details of the managed runtime memory manager. If you want to see how much memory your app is really using at any point in time, open PerfMon and use the .NET Memory counters in there. The memory that your application uses, when freed, gets returned to the Managed Heap in the .NET CLR, not to Windows. This is because allocations for future objects are faster is there is memory available in the managed heap. If not, then a block of memory has to be allocated from Windows, put in the managed heap, then your object allocated. This takes more time. Unless you're really worried about how much memory your app is actually using, you're worried about nothing. The .NET CLR memory manager is very good at it's job and tunes itself depending on how your app is running. It's constantly watching how your app allocates and frees memory and adjusts the size of the managed heap every once in a while. But, if Windows needs the memory back, the .NET CLR will happily return any memory it can to Windows.
A guide to posting questions on CodeProject[^]
Dave KreskowiakThanks Dave! The problem was in RaptorDB when I was inserting 100K docs into it which uses around 600Mb of ram, this was fixed by freeing internal cache data after saving to disk which brought it back down to around 150Mb, however restarting the app with the same data files only uses 70Mb and works like a charm, so I was perplexed where the difference was since I released all my cached data. Anyway the problem of memory usage is fixed but I still get a nagging feeling about the difference.
A programmer walks into a bar and asks the bartender for 1.00000000000003123939 root beers. Bartender says, I'll have to charge you extra, that's a root beer float. Programmer says, better make it a double then.
-
After creating a lot of objects and then freeing them in my code and calling
GC.Collect(2)the memory footprint does not go back to the pre allocation point in the app. Using a tool called VMMap (great tool by the way!) it show that the memory is in the GC's hands (out of the application's). Is there a way to get around this?A programmer walks into a bar and asks the bartender for 1.00000000000003123939 root beers. Bartender says, I'll have to charge you extra, that's a root beer float. Programmer says, better make it a double then.
Do GC.Collect() for reasearch reasons and so on. But for real life applications its not an good idea, because it blocks all threads. I do GC.Collect() only on 32 Bit machince, in situations where i encounter a OutOfMemory Exception, or in situations where i know, that chances are very high that the next lines of code will run into out of memory.
-
Task Manager is showing you the memory the the .NET CLR has RESERVED for your application, not how much it's actually using. The same goes for VMMAP. Neither tool goes into any of the details of the managed runtime memory manager. If you want to see how much memory your app is really using at any point in time, open PerfMon and use the .NET Memory counters in there. The memory that your application uses, when freed, gets returned to the Managed Heap in the .NET CLR, not to Windows. This is because allocations for future objects are faster is there is memory available in the managed heap. If not, then a block of memory has to be allocated from Windows, put in the managed heap, then your object allocated. This takes more time. Unless you're really worried about how much memory your app is actually using, you're worried about nothing. The .NET CLR memory manager is very good at it's job and tunes itself depending on how your app is running. It's constantly watching how your app allocates and frees memory and adjusts the size of the managed heap every once in a while. But, if Windows needs the memory back, the .NET CLR will happily return any memory it can to Windows.
A guide to posting questions on CodeProject[^]
Dave KreskowiakThat "diamond reply," imho, Dave, deserves to be enshrined in a Tip-Trick. yours, Bill
~ “This isn't right; this isn't even wrong." Wolfgang Pauli, commenting on a physics paper submitted for a journal
-
That "diamond reply," imho, Dave, deserves to be enshrined in a Tip-Trick. yours, Bill
~ “This isn't right; this isn't even wrong." Wolfgang Pauli, commenting on a physics paper submitted for a journal
I should do that. It's an answer that comes up time and time again. The problem is how to get it to show up when a user does NOT Google for it! ;)
A guide to posting questions on CodeProject[^]
Dave Kreskowiak