From: Bo Persson on
David Ching wrote:
> "David Ching" <dc(a)remove-this.dcsoft.com> wrote in message
> news:5E5EA6F1-9723-4AF4-A32A-53068295AEC4(a)microsoft.com...
>> I just can't believe there isn't a simple utility to tell you
>> grossly whether or not your app is not huge portions of memory in
>> a timely fashion.
>>
>
> OK, I wrote a simple MFC dialog based app (ha, it's been awhile
> since I've done that, too much time in .NET-land, and it's like
> riding a bike, you just don't forget how!) that simply allocates a
> 1 MB block each time button A is clicked, and deallocates one of
> the allocated blocks (in LIFO order), each time button B is
> clicked. Knock on wood, trusty Process Explorer updates these
> metrics by 1 MB, like clockwork, each time either button is
> clicked:
>
> Process Explorer Metrics
> ----------------------------
> Virtual Memory
> * Private Bytes
> * Virtual Size
>
> Physical Memory
> * Working Set
> * WS Private
>
>
> The Windows 7 Task Manager also reliably both increments and
> decrements the following metric as 1 MB blocks are allocated and
> deallocated:
> Windows 7 Task Manager
> ------------------------------
> * Memory - Commit Size
>
>
> So, it would appear Task Manager and even more so, Process
> Explorer, are great tools for tracking memory leaks!
>

Not necessarily. :-)

If you allocate LARGE blocks, the heap manager might allocate and
release these to the OS separately. If you allocate and release a lot
of smaller blocks, the heap manager will likely keep these for future
reuse.


Bo Persson