if (vec.capacity() / vec.size() > 2) {
  vector<int> tmp;
  tmp.reserve(vec.size());
  copy(begin(vec), end(vec), back_inserter(tmp));
  swap(tmp, vec);
}

bigAssCollection[key] = move(vec);

CK>if (vec.capacity() / vec.size() > 2) {
CK>  vector<int> tmp;
CK>  tmp.reserve(vec.size());
CK>  copy(begin(vec), end(vec), back_inserter(tmp));
CK>  swap(tmp, vec);
CK>}

CK>bigAssCollection[key] = move(vec);
CK>

std::vector<T> acc
for( 1000000 раз ) {
    acc.clear()
    заполняем acc
    vector<T> tmp;
    tmp.reserve( acc.size() )
    bigCollection[key] =move( tmp )
}

Since C++11, STL ships with two hash tables: std::unordered_map and std::unordered_set. They where designed to have an interface very close to the old (ordered) std::map and std::set. The advantage of this is that it's easy to port old std::map/std::set code to the new unordered variants and get a nice speed boost. The disadvantage, however, is that STL:s hash tables are much slower than they have to be. The reason is that the standard mandate that any insertion or deletion of an element must not affect pointers to other elements. This means a rehash may not move elements in memory. The memory for an element must thus be allocated once, and never moved. This means that C++11's hash tables must have an array that points to its elements rather than contain them directly. This means that any lookup in the hash table incurs one extra pointer chasing, and thus a likely cache miss. As we shall see, this may make a hash table an order of magnitude slower than it has to be.