Dealocating large objects?

[none]

In my code I iterate a container of objects:


typename ContainerType::iterator it = jobs.begin();
while(it != jobs.end()) {
JobType job = (*it);

// Loads large data sets
job.Setup();

// do process 1


// do process 2



// dealocate the job!

it++;
}


When job.Setup() is called a number of very large data files are loaded into the job object. After
the job has been processed I therefore need to "kill" it from memory before setting up the following
job.

But how do I make sure that the current job object is completely removed from memory before setting
up the following job?

 

[Victor Bazarov]

In my code I iterate a container of objects:


typename ContainerType::iterator it = jobs.begin();
while(it != jobs.end()) {
JobType job = (*it);

I think you meant to do

JobType& job = *it;

Otherwise you're copying it here. Or did you mean to copy it?

// Loads large data sets
job.Setup();

// do process 1


// do process 2



// dealocate the job!

it++;
}


When job.Setup() is called a number of very large data files are loaded
into the job object. After the job has been processed I therefore need
to "kill" it from memory before setting up the following job.

So, just like your JobType has the 'Setup' function, add a 'WrapUp'
function which will deallocate all the stuff from the 'job'. Or, if you
do mean to create a local copy of the JobType object, let the destructor
take care of the deallocation.

But how do I make sure that the current job object is completely removed
from memory before setting up the following job?

Not sure what you mean by "completely removed from memory".

Generally speaking, you don't need to worry about memory freeing up as
long as you make all the right moves ('delete' all your 'new' pointers,
etc.) You need to rely on the system doing it for you. If you want to
have more control over what goes where and how, write your own
allocator. GIYF

V

 

[none]

I think you meant to do

JobType& job = *it;

Otherwise you're copying it here. Or did you mean to copy it?

I am not sure here. If I do:

JobType& job = *it;

then the call to Setup() will load the data into the reference which will survive in the container
during all the iterations and thereby accumulating the size of the container (eating up all the
memory).

But I just do:

JobType job = *it;

I assume that the loaded data will be delete after each iteration which is good!

So, just like your JobType has the 'Setup' function, add a 'WrapUp'
function which will deallocate all the stuff from the 'job'. Or, if you
do mean to create a local copy of the JobType object, let the destructor
take care of the deallocation.

Actually I don't create anything in Setup() using new.

 

[none]

I am not sure here. If I do:

JobType& job = *it;

then the call to Setup() will load the data into the reference which
will survive in the container during all the iterations and thereby
accumulating the size of the container (eating up all the memory).

But I just do:

JobType job = *it;

I assume that the loaded data will be delete after each iteration which
is good!

Ok neither :

JobType job = *it;

or

JobType& job = *it;

seems to reduce the memory consumption.

Only the first job gets done while the second terminates during the Setup call because of not enough
memory.

Any ideas on how I wipe the previous job completely before continuing to the second in the while loop?

 

[Abhishek Padmanabh]

Ok neither :

JobType job = *it;

or

JobType& job = *it;

seems to reduce the memory consumption.

Only the first job gets done while the second terminates during the Setup
call because of not enough memory.

Any ideas on how I wipe the previous job completely before continuing to
the second in the while loop?

You might not be creating anything yourself in SetUp() using new but some
other routine or object must be keeping the memory and that might be needing
an explicit release. Destructors are not only helpful in deallocating memory
allocated by new/new[] or other memory allocation routines but just about
any resource that the class' object might acquire during its lifetime
provided, you wish it to deallocate that. It could be file handles, pointers
to other objects that actually are holding up the data, etc.

You will have to find out what exactly in SetUp call is taking up the
memory, and why isn't it being freed up. That is what is depriving the
second interation of the required memory. It could also be that you would
need to optimize the way you are using memory using a different algorithm
inside SetUp() and while doing the job.