Re: Memory problems (possibly very easy question)


Joseph M. Newcomer skrev:
See below...
On 29 Nov 2006 08:03:58 -0800, "peter koch" <peter.koch.larsen@xxxxxxxxx> wrote:


Joseph M. Newcomer skrev:
The question sounds more like the "I freed the memory, why didn't my program get smaller?"
(Usually based on some value like theprogram size in Task Manager). The program doesn't
get smaller because it isn't supposed to get smaller; that's not how storage allocators
work. It is a common delusion that if you free storage your program should get smaller;
it can't, and it won't. The subtleties of this are discussed in my essay on storage
mangement on my MVP Tips site.

I disagree. Read this excerpt from the OP:
But my mem usage does not reduce... so when i run the process a few
times the usage gets really really large, and windows gives me virtual
memory usage warnings (or similar).
****
This indicates the storage is not being released, since the footprint continues to grow.
But releasing it does not reduce the footprint, it merely keeps it from growing as the
released storage is reused. In the case of massively large vectors, however, the
fragmentation may mean that the footprint will continue to grow, for the reasons described
in my essay. That's yet a different problem, but that requires yet a different solution
than those posed thus far. Memory fragmentation is one of the major problems one faces in
dealing with structures of this nature. But that isn't what the question was...the first
answer, that each of the individual elements needs to be deleted, has to be addressed
first.
****

Essentially: every time the process is run memory increases. This is a
very strong indication that memory is not reused.
****
There are two concepts of "reuse" here, and even if the objects are all freed, the space
for the array itself may be freed, fragmented, and then reallocated in a new place, thus
causing the footprint to extend indefinitely. But the memory would be freed; it just
couldn't be reused. So the question remains open. Is it failure to release, or is it
fragmentation? Until the issue about releasing the objects in the array is answered, it
isn't possible to determine if the fragmentation problem exists. If the fragmentation
problem exists, there are two or three alternative architectures that can be applied, but
the question is still open.

I see no possibility for fragmentation. Theres a loop: (1) allocate
memory (b) free memory
This will not cause any fragmentation. I agree that theres a small
amount of freeing memory for the vector (as reallocations take place),
but this will be valid for the first run of the loop.

The only logical answer is that memory does not get released. I look
forward to hear if the OP solves his problem, but I'd bet its related
to a real memory leak somewhere - not fragmentation.

/Peter

.

Relevant Pages

  • Re: Memory problems (possibly very easy question)
    ... It is a common delusion that if you free storage your program should get smaller; ... memory usage warnings. ... This indicates the storage is not being released, since the footprint continues to grow. ... fragmentation may mean that the footprint will continue to grow, ...
    (microsoft.public.vc.mfc)
  • Re: Memory problems (possibly very easy question)
    ... once you've solved the memory leak problem and the fragmentation ... It is a common delusion that if you free storage your program should get smaller; ... But releasing it does not reduce the footprint, it merely keeps it from growing as the ...
    (microsoft.public.vc.mfc)
  • Re: Memory problems (possibly very easy question)
    ... Now allocate 25,000 objects. ... Once you get the leaks fixed, fragmentation becomes your worst enemy. ... memory usage warnings. ... But releasing it does not reduce the footprint, it merely keeps it from growing as the ...
    (microsoft.public.vc.mfc)
  • Re: Explorer unresponsive
    ... Jeff Stanton wrote: ... boxes before Peak Memory Usage and Virtual Memory size. ... Volume fragmentation ... Event Viewer: Event Type: Error ...
    (microsoft.public.windowsxp.basics)
  • Re: Explorer unresponsive
    ... Jeff Stanton wrote: ... boxes before Peak Memory Usage and Virtual Memory size. ... Volume fragmentation ... Event Viewer: Event Type: Error ...
    (microsoft.public.windowsxp.basics)