stl vector performance

[barbaros]

Hello,

Is there any advantage in performing a reserve operation before
inserting a large number of zeroes in an empty vector ?

Let me be more specific. In the code below, does the second line bring
any increase in performance ?

vector<float> v;
v.reserve(1000);
v.insert(v.end(),1000,0.0);

Note: I am not interested in using directly the constructor, e.g.
vector<float> v(1000,0.0);

Thank you. Cristian Barbarosie
http://cmaf.ptmat.fc.ul.pt/~barbaros/

 

[Bo Persson]

Hello,

Is there any advantage in performing a reserve operation before
inserting a large number of zeroes in an empty vector ?

Let me be more specific. In the code below, does the second line
bring any increase in performance ?

vector<float> v;
v.reserve(1000);
v.insert(v.end(),1000,0.0);

Highly unlikely. The insert function sees that you want to add 1000
new members, and can do a reserve internally if needed.

Generally, you should not try to outsmart your compiler. It hardly
ever works!



Bo Persson

 

[Juha Nieminen]

Highly unlikely. The insert function sees that you want to add 1000
new members, and can do a reserve internally if needed.

Generally, you should not try to outsmart your compiler. It hardly
ever works!

I think in this case it's completely the work of the library rather
than the compiler.

 

[Juha Nieminen]

Hello,

Is there any advantage in performing a reserve operation before
inserting a large number of zeroes in an empty vector ?

Let me be more specific. In the code below, does the second line bring
any increase in performance ?

vector<float> v;
v.reserve(1000);
v.insert(v.end(),1000,0.0);

The implementation of std::vector in your compiler would have to be
really, really stupid if its insert() function didn't allocate memory
for all the inserted elements in one single step, given that it knows
exactly how many of them are being inserted.

If you inserted using a forward iterator range, then there might be a
benefit in reserving space for the new elements (if you know how many of
them there are) because the library has no way of knowing in advance
(ie. before traversing the iterator range) how many elements will be
inserted. (If you use a random access iterator range, then some library
implementations might use template magic to detect that this is the
case, in which case it can allocate the necessary memory in advance.
However, this might not be the case with all possible STL implementations.)

 

[barbaros]

Thank you all for your answers.

So, I understand the following four pieces of code should be roughly
equivalent

1: vector<float> v;
v.reserve(1000);
v.insert(v.end(),1000,0.0f);

2: vector<float> v;
v.insert(v.end(),1000,0.0f);

3: vector<float> v;
v = vector<float>(1000, 0.0f);

4: vector<float> v;
vector<float>(1000, 0.0f).swap(v);

 

[barbaros]

Why, do you have any timing results to share?

No, I was only trying to understand how things work in STL.

By the way, here is why I need this vector:
http://cmaf.ptmat.fc.ul.pt/~barbaros/en/tensor.cpp
It is a class for implementing a tensor of an arbitrary order.
A tensor is like a matrix, but can have more than two indices.
Vectors are order one tensors, matrices are order two tensors.

Cristian Barbarosie
http://cmaf.ptmat.fc.ul.pt/~barbaros

 

[mojmir]

It is a class for implementing a tensor of an arbitrary order.

in many situations you know the order ahead and therefore you
can avoid unnecessary allocations. some solution based on
parametrisation "template <size_t Order>" may perform better.
depends on our needs, of course.

best regards,
mojmir

 

[barbaros]

in many situations you know the order ahead and therefore you
can avoid unnecessary allocations. some solution based on
parametrisation "template <size_t Order>" may perform better.
depends on our needs, of course.

I do not know how to parametrize the number of (int) arguments of the
constructor or of the operator().

Is it possible ?

Cristian Barbarosie
http://cmaf.ptmat.fc.ul.pt/~barbaros

 

[James Kanze]

I think in this case it's completely the work of the library
rather than the compiler.

And the complexity requirements of the function in the standard
require the implementation of the library to do the right thing.