Will the std::vector copy assignment operator avoid releasing and reallocating memory if possible?

Question

I have a function copying one vector to another (among many other things). A simplified version of the code is below.

void Fun(std::vector<double> &in, std::vector<double> &out) {
    out = in;
}

I care about maximizing efficiency because the function will be run many times. So, I would like to avoid reallocating memory as much as possible. The vector 'in' may already have a significant amount of memory reserved to it. So, if I made a manual implementation, I am sure that I could accomplish this. For example:

void Fun(std::vector<double> &in, std::vector<double> &out) {
    out.resize(in.size());//note - if the capacity of out is greater than in.size(), this will involve no memory release or allocation
    for (unsigned int i = 0;i<in.size();i++) {
        out[i] = in[i];
    }
}

If in.size() is less than the existing capacity of out, then this latter implementation will not release or assign any new heap memory.

The question is - would my original implementation do the same? Ie, would std::vector know to automatically do this in a memory efficient way if I simply did "out = in;"?

In particular, I am concerned that perhaps the "out = in;" line might do something like release all the heap memory currently allocated to out, and then reallocate it. Something effectively equivalent to this:

void Fun(std::vector<double> &in, std::vector<double> &out) {
    out.clear();
    out.shrink_to_fit();//releasing memory from heap
    out.resize(in.size());//reallocating memory from heap
    for (unsigned int i = 0;i<in.size();i++) {
        out[i] = in[i];
    }
}

Answer 1

The implementation of std::vector::operator= in your C++ library came into existence a very long time ago. It is a near certainty that its authors knew what they were doing and, in combination with a modern C++ compiler, it will generate optimal code to minimize the amount of work and dynamic allocation. The authors of operator= are very smart. They're smarter than me. They're smarter than you.

It's fairly likely that the shown attempt to optimize this operation will, at best, come out even. At its worst, when out is smaller that in.size() it'll end up spinning its wheels with a bunch of pointless zero-initialization in resize(), unless the compiler is smart enough to optimize it out.

If there's specific knowledge that in a particular use case the stock out=in; results in measurable suboptimal performance, then some kind of a micro-optimization might be prudent; but a mere "care about maximizing efficiency" should have something specific to evaluate.

Answer 2

The vector 'in' may already have a significant amount of memory reserved to it.

[...] would my original implementation do the same?

I don't know of any implementation that reserves an excess of memory just because the vector being copied from has a lot of .capacity(). Also, your second snippet doesn't reserve more memory than needed to store all elements in in - and it does it by first default constructing the extra elements and then assigning new values to them. For doubles, it probably doesn't matter much, but for non-trivial types, it can make a noticeable difference. The original out = in; will never be slower than the code in your second snippet.

If you want to reserve as much memory as in has reserved, you can do it manually with .reserve():

void Fun(const std::vector<double>& in, std::vector<double>& out) {
    out.clear();
    out.reserve(in.capacity());
    out = in;
}

---

Regarding the additions to your question:

In particular, I am concerned that perhaps the out = in; line might do something like release all the heap memory currently allocated to out, and then reallocate it. Something effectively equivalent to this:

void Fun(std::vector<double> &in, std::vector<double> &out) {
    out.clear();
    out.shrink_to_fit();//releasing memory from heap
    out.resize(in.size());//reallocating memory from heap
    for (unsigned int i = 0;i<in.size();i++) {
       out[i] = in[i];
    }
}

No, that is highly unlikely. From cppreferece:

[...] Otherwise, the memory owned by *this may be reused when possible. In any case, the elements originally belonging to *this may be either destroyed or replaced by element-wise copy-assignment.

A sane implementation would do what it can to reuse the memory it already has allocated. The implementation will likely use different approaches for different types to make the copy assignment as effective as possible. For trivially copyable types (like double), it may out.resize(in.size()) and then std::copy. For more complex types, it may out.reserve(in.size());, copy assign the existing elements in out and then copy construct the rest (if out.size() < in.size()) - or it may out.clear(); out.reserve(in.size()); and then copy construct them all. It'll depend on the type in the container.

If out has more capacity than in, it will (almost certainly) not shrink_to_fit (which in theory could cause an unnecessary reallocation) but instead keep the over allocation for later use as demonstanted in this example where all major implementations keep the capacity even after copy assignment of a much smaller vector.