As Andrew's described (http://www.red-gate.com/messageboard/vi ... php?t=9190
), there are a few things that can cause .NET memory usage to appear not to change after a garbage collection:
* The # bytes in all heaps counter is often not accurate as it's only updated after a garbage collection, and there are times when .NET allocates more memory without causing a GC (and rare times when it releases memory outside of a GC). The private bytes counter is updated in real time.
* Fragmentation of the large object heap can prevent .NET from releasing memory back to the system. You can see free space in .NET heaps in the memory profiler, as well as the largest free contiguous block: if there is a lot of free space but the largest contiguous block is small then fragmentation is occurring.
* Objects referenced by objects with finalizers require at least 2 garbage collection cycles to be removed from memory, and possibly more if these references themselves have finalizers.
* .NET can maintain a pool of free memory for future object allocations if it thinks that there will be a lot of them (this allows it to postpone future garbage collections). It might decide to release this back to the system if there is another GC and not much of the free memory is used. This is often beneficial for the performance of server style applications.