# Fastest way of freeing up a vector

This topic is 4884 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

## Recommended Posts

I have 4 vector arrays of pointers to objects in a class, when the destructor to the class is called the elements are deleted and the vector is cleared, this is fine but it can take 10-15 seconds to remove everything, what is the quickest way to free all memory the pointers point to? This is what i have at the moment:
	~OBJObject()
{
for (vector<OBJFace*>::iterator i = pFaces.begin(); i != pFaces.end(); i++)
delete *i;
for (vector<CVec3*>::iterator i = pVertices.begin(); i != pVertices.end(); i++)
delete *i;
for (vector<CVec2*>::iterator i = pTexCoords.begin(); i != pTexCoords.end(); i++)
delete *i;
for (vector<CVec3*>::iterator i = pNormals.begin(); i != pNormals.end(); i++)
delete *i;

pFaces.clear();
pVertices.clear();
pTexCoords.clear();
pNormals.clear();
}


Is there a faster way???

##### Share on other sites
Quote:
 Original post by KazadeIs there a faster way???

As something as low level as 2/3-vector storing pointers to them in a dynamic array is basically committing suicide unless you have a very, very good reason. For these kind of low-level types store the actual type and not a pointer to it, when std::vector is destroyed it will deallocate a chunk of memory all in one go and not per-element like you are doing. if you need to incrementally initialize/add elements and you know (roughly) how many elements you need in advance use std::vector::reserve and then std::vector::push_back.

##### Share on other sites
look into pooling memory clicky

##### Share on other sites
For future reference, if you're storing pointers to objects allocated on the heap in a vector, and you want them to be deleted when you erase the vector, then store a vector full of smart pointers, such as boost::shared_ptr. Then the memory will be automatically reclaimed when the vector is erased. This is safer, because you can't forget to delete anything.

This would mean your destructor code could be replaced by this.

~OBJObject(){                pFaces.clear();		pVertices.clear();		pTexCoords.clear();		pNormals.clear();}

This should be lot faster, because in your code you're iterating through each array, deleting each member, whereas this version just calls clear, and lets the destructor of boost::shared_ptr do the work of deleting the items in the array.

##### Share on other sites
Quote:
 Original post by petewoodlook into pooling

I.

typedef std::vector<CVec3, boost::pool_allocator<CVec3> > pool_vec3_vec;

##### Share on other sites
Quote:
 Original post by OxyacetyleneThis would mean your destructor code could be replaced by this.

No destructor needed. You wouldn't need to call clear on the vectors since they clear themselves when destroyed.

##### Share on other sites
Quote:
Original post by SiCrane
Quote:
 Original post by OxyacetyleneThis would mean your destructor code could be replaced by this.

No destructor needed. You wouldn't need to call clear on the vectors since they clear themselves when destroyed.

D'oh, I should have remembered that, especially considering it's one of the reasons I use std::vector over dynamic arrays. *slaps head*

##### Share on other sites
Quote:
Original post by SiCrane
Quote:
 Original post by OxyacetyleneThis would mean your destructor code could be replaced by this.

No destructor needed. You wouldn't need to call clear on the vectors since they clear themselves when destroyed.

I was just about to say [grin], and i don't think it will be any faster (at least nothing significantly noticeable) infact its most likely to be slightly slower (with a slight alteration to the original code) hence the existance of Boost Pointer Container Library.

I still stand by what i said earlier, having something like a vertex buffer using an array of pointers to 2/3-vector is silly, i'll just quote myself:

Quote:
 Original post by snk_kidtypedef std::vector > pool_vec3_vec;

##### Share on other sites
However, smart pointers would probably be even slower as they have to perform refernce counting AND still have to call delete on every object.

The speed problem here is almost certainly related to freeing a large amount of small heap-allocated memory.

There are 2 approaches to solving this that I can see:

1:
Use vector::reserve to pre-allocate the memory and hold the objects by value

2:
Use a pool allocator and hold objects by value again

EDIT:
I wouldn't be in the least bit suprised if simply switching from pointers to objects gave you a dramatic speed increase, even without reserve or a custom allocator.

##### Share on other sites
Yeah, I'm beginning to see my comment about shared_ptr being a faster solution was a bit uninformed, so I take it back.

My original thinking was that I thought it'd probably be faster to call delete[] once for each array, (which I assume is what vector::clear does? Although assumptions are a bad thing.) rather than calling delete once for each member of the array, but I wasn't thinking about the fact that the destructor of shared_ptr is essentially doing the same thing. I also wasn't thinking about the overhead of reference counting.

I wasn't disagreeing that switching from pointers to objects was a good idea though, I just wanted to say that using shared_ptr is a better solution when you have to store objects on the heap. (even though it's not actually faster)

Just wanted to clear that up, since there's nothing worse than someone saying something uninformed, and then failing to admit that they were wrong later on.

• ### What is your GameDev Story?

In 2019 we are celebrating 20 years of GameDev.net! Share your GameDev Story with us.

• 15
• 9
• 11
• 9
• 9
• ### Forum Statistics

• Total Topics
634134
• Total Posts
3015743
×