Vector memory management

Question

What is the difference looking from memory menagement site between using one vector class member for all temp vectors used in functions:

class A
{
   private:
   vector<Type> m_vector;
}

void fnc()
{
   m_vector.clear();
   m_vector.push_back();
   //further operations on vector
}

and creating temp vectors inside of functions:

void fnc()
{
    vector<Type> vector;
    //further operations on vector
}

I suppose first option results in less memory fragmentation, cause we are doing one allocation and using this area, and in second case we are allocating memory for vectors in different functions which results in memory fragmentation.

What are the pros and cons of this vector usages? Which one should I use when I have class which needs many vectors in its functions? And which one is better looking from memory menagement site?

score 9 · Accepted Answer · edited Jun 04 '12 at 12:20

9

Your solution might be better from memory management point of view because of fragmentation and fewer allocations/deallocations but :

You become less thread safe in a multithreaded environment - you might need to implement some synchronization in each method around the use of the vector
You need to remember to clear the vector's contents in each method

edited Jun 04 '12 at 12:20

Luchian Grigore

253,575
64
457
625

answered Jun 04 '12 at 11:40

Ventsyslav Raikov

6,882
1
25
28

+1 for squarely addressing the question and providing meaningful cons. – Tony Delroy Jun 04 '12 at 11:45
@Luchian Grigore - As you see the asker's example he clears the vector before starting to work with it because he wants to use it as a 'new' vector allocated on the stack in the method's body. If you don't do that you're left with the contents of the previous usage. – Ventsyslav Raikov Jun 04 '12 at 12:18
It is less thread safe because if you call 2 methods on one object(containing the vector) in 2 threads at the same time they should synchronize on the vector(at least) so that the elements they put/remove/update don't mess with each other. – Ventsyslav Raikov Jun 04 '12 at 12:19
OK sorry, I see now you're addressing the option where the vector is a member. Yup, makes sense then. – Luchian Grigore Jun 04 '12 at 12:21
@Luchian Grigore - it is not cleared because there is no scope if you use it as a member of a class - the scope is the lifetime of the object which contains the vector. In MT env it will be the same vector if it is the same object(which contains it) being accessed by multiple threads. – Ventsyslav Raikov Jun 04 '12 at 12:21

score 6 · Answer 2 · answered Jun 04 '12 at 11:34

6

Simple rule:
If you want the vector to exist till the lifetime of your class object make it a class member else don't.

In short, You should use it as member if its lifetime is tied to the lifetime of the object.
If not, all you need is local vectors.
Whether the first or second approach is more appropriate for your usage is Micro-Optimization avoid them unless your usage is expected to be heavy enough to be worried avoid it.

answered Jun 04 '12 at 11:34

Alok Save

202,538
53
430
533

1

Downvoted because it offers a good rule of thumb with no _justification_. The question correctly lists some potential benefits to the technique, you've just said those benefits aren't worth much unless they are. Well, yeah. The Q shows understanding of lifetime. You haven't mentioned reasons for the general guideline - readability and maintainability benefits, localisation, avoiding high-watermark memory usage, thread safety. I don't think it adds anything to the questioners understanding of the tradeoffs beyond an "in my experience this is micro-optimsation". – Tony Delroy Jun 04 '12 at 12:23
And while I wouldn't normally bother to downvote an answer that was simply of little value but not actively wrong, in this case I felt you'd got an early-mover advantage and votes from an "argument from authority" position, and wanted to help Bond's answer nudge past you - so you lucked out! ;-) – Tony Delroy Jun 04 '12 at 12:30

score 1 · Answer 3 · answered Jun 04 '12 at 11:37

1

Don't make a member vector just for the purpose of re-usage. Whether something is a member or not should be based on the logic of the class.

answered Jun 04 '12 at 11:37

Luchian Grigore

253,575
64
457
625

But why not to create a re-usable vector? "Just" a matter of style or are there any other concerns? – TeaOverflow Jun 04 '12 at 11:40
Yes but what if creating a lot of vectors in function creates huge memory segmentation? – krzych Jun 04 '12 at 11:45
@krzych have you measured anything? Is your memory really fragmented? If it is, is it a huge concern? – Luchian Grigore Jun 04 '12 at 12:05
How to measure memory fragmentation on Windows ( http://stackoverflow.com/questions/10835061/tools-for-checking-memory-fragmentation ). I think that it could be a problem in my project. – krzych Jun 04 '12 at 12:13
@krzych I think you should focus first on writing readable code, and afterwards try to do micro-optimizations. – Luchian Grigore Jun 04 '12 at 12:15
krzych: if you haven't even profiled and have no specific reason to suspect it, the chance that heap fragmentation just happens to be one of your more significant problems is very small. Programmer hunches about where performance bottlenecks are are famously unreliable. Rather than getting fragmentation statistics, you should focus on profiling information to see if your memory allocations are taking too long, then only if they are - work out why. – Tony Delroy Jun 04 '12 at 12:34

Vector memory management

3 Answers3