Re: Memory increases linearly
"Faisal" <faisalm83@gmail.com> ha scritto nel messaggio
news:edcaeb1b-5468-43df-840f-0d9ed643fa78@d19g2000prm.googlegroups.com...
I tried with application verifier and Rational Purify. I coudn't find
any memory or handle leak with these two.
Could it be possible for you to make sure that you free useless memory
resources as soon as possible?
I mean: you may be doing lots of new allocations, so occupied memory
accumulates, and you can do a release of all the allocated memory in the
end.
That means no memory leaks, sure. But lots of useless memory reserved.
Or you could realese allocated memory as soon as it becomes useless. This
may make the code a little bit more complicated, but in that case you don't
have useless memory still allocated when there is no need.
For example, suppose you create some objects using a factory function, call
it ObjectsFactory::CreateObject(). This factory method keeps a list of all
allocated objects. The factory class ObjectsFactory then has a method
ObjectsFactory::DeleteAll(), which deletes all allocated objects.
So, in your code you have:
ObjectsFactory g_objFactory;
Object * o1 = g_objFactory.CreateObject();
Object * o2 = g_objFactory.CreateObject();
...use o1, use o2
...
Object oN = g_objFactory.CreateObject();
At some point of the code, you don't need to use o1, or o2, or o3 instances,
but you have them in memory, occupying memory space.
Than, say just before quitting the app, you do a g_objFactory.DeleteAll();
This way you don't have memory leaks, but you had lots of *useless* objects
occupying precious memory.
A better approach would be to release objects as soon as possible, e.g.
Object * o1 = ... create it
Object * o2 = ... create it
use o1, use o2
you don't need o1 and o2, so just remove them ASAP:
delete o1;
delete o2;
... allocate other objects
... use them
... free them
This is kind of the difference between a garbage collector (GC) system like
..NET or Java and C++.
C++ has deterministic memory release system, via destructors or reference
counted shared_ptr: with shared_ptr, as soon as the ref count gets 0 (i.e.
no one needs the object anymore), the object is deleted.
Instead, with GC, you allocate objects and you forget about them. If under
memory pressure, the GC thread will run a garbage collecting cycle,
detecting unused objects and deleting them. But, before that, there will be
several unused objects living (and occupying room) in the managed heap.
This is one of the reasons why .NET has a big memory footprint if compared
to native.
HTH,
Giovanni