0

I'm trying to make an application more memory efficient and in order to do that I need to understand its current memory usage. So I've got a little console program where I have it pause at various steps in the process so I can analyze its memory usage with various tools. This is a C++ program using standard STL allocators and containers (unique_ptr, vector, map, etc).

Unfortunately I've apparently run into an issue with how the Windows heap manager works. My understanding is that as the heap usage grows, it commits more memory from the operating system. But as the heap usage shrinks, it does NOT decommit that memory. See this answer and this comment.

Ultimately I can tell how much heap my program is actually using by examining it in windbg with the !heap extension, but that's a bit tedious and it would be nice to be able to use something easier like process explorer or performance monitor. Also, I'm going to get complaints when people open up task manager and see this misleading information.

So I guess my question is A) is there a way to actually decommit heap memory without exiting the process or, failing that, B) is there a strategy I can use to avoid this? (custom allocator?)

trincot
  • 317,000
  • 35
  • 244
  • 286
Luke
  • 11,211
  • 2
  • 27
  • 38
  • Releasing allocated memory adds the blocks back to the free-list. To be used for future allocations. Only in the case that enough memory was freed and coalesced into a large enough *contiguous* chunk of address space will the heap manager call VirtualFree(). Could happen, just not that likely, especially not for a low-fragmentation heap. It takes but a single allocation to split the chunk. It just doesn't matter, it is virtual memory. – Hans Passant Feb 24 '16 at 18:17
  • I don't understand what you mean by "it just doesn't matter"; the memory is still committed and taking up space in RAM or page file. In an extreme scenario it was a few GB. – Luke Feb 24 '16 at 20:56

0 Answers0