Sometimes you just need a good GC.Collect ...
From the VistaDB blog: To Collect or not to Collect.
One of the first things it seems most people do when they get the code to VistaDB is remove the GC.Collect() call we have in the MinimizeMemory code for the Tree class. This class specifically is used to hold portions of the database, indexes, etc in RAM. Periodically it is combed to attempt and minimize the number of nodes kept in RAM.
They've done a bit of testing with 3.5 and found the performance with and without the call to be much more comparable than previous versions.
Does this mean you should use GC.Collect? Generally, the answer is still no. I've noticed a few times that a GC.Collect with Marshal.FinalRealseComObject can improve reliability in certain types of managed COM Interop application scenarios, but I haven't generally found too many scenarios where a GC.Collect was useful.
Their testing:
2.0 (no SP installed):
Dot Net 2 Runtime Results
Without Collect
Runtime: 259 Seconds
Peak Memory: 289,742 Kb
Ending Memory: 165,756 KbWith Collect
Runtime: 290 Seconds
Peak Memory: 68,788 Kb
Ending Memory: 58,088 Kb
And with 3.5 installed:
Without Collect Dot Net 3.5 Runtime
Runtime: 233 Seconds
Peak Memory: 62,880 Kb
Ending Memory: 70,824 KbWith Collect Dot Net 3.5 Runtime
Runtime: 278 Seconds
Peak Memory: 53,992 Kb
Ending Memory: 56,300 Kb
Comments
I've found that after doing anything with a large number of images (or a small number of large images) in WPF/WIC, a GC.Collect is absolutely required. The GC can't seem to figure out that it needs to collect sometimes, and that leads to some nasty out of memory errors.
To test things, I usually make a 'Collect' debug button that I can use to force a collection. Very useful for finding leaks and other issues around keeping references around too long/etc.
Posted by: Ben Vanik | December 31, 2007 12:50 PM
WPF/WIC use a lot of COM internally and I wonder if that is why it can help...? (Just speculating).
Posted by: Aaron | December 31, 2007 2:43 PM