From: Bo Persson on 31 May 2010 11:38 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 |