You appear to be copying vectors around a lot. For example:
1 2
|
vector<int> current_combination;
current_combination=CombNK[i];
|
This code declares a new vector and then copies the CombNK[i] vector into it. If you just want a different name for the CombNK[i] vector, rather than using it directly everywhere, use a reference.
|
const vector<int>& current_combination = CombNK[i];
|
This does not copy the contents of the vector.
This looks like unnecessary copying also:
1 2 3
|
vector<vector<double>> zeros(N,vector<double>(N));
Gout=zeros;
for(int i=0;i<N;i++) Gout[i].push_back(1);
|
To eliminate the possible copying (the compiler can sometimes optimize out temporaries) you would need to declare and return Gout locally (possibly complicated), or use vector::swap to move the contents of zeros to Gout without copying, or use resize. vector::swap just swaps the 3 pointers contained in the vector; it does not copy the elements.
1 2 3
|
vector<vector<double>> zeros(N,vector<double>(N));
Gout.swap(zeros); // side effect; zeros gets previous contents of Gout before going out of scope
for(int i=0;i<N;i++) Gout[i].push_back(1);
|
Resize:
1 2 3 4
|
Gout.clear(); // empty the vector; size = 0
Gout.resize(N,vector<double>(N)); // reinitialize with what would have been in zeros;
// avoids copy of zeros into Gout.
for(int i=0;i<N;i++) Gout[i].push_back(1);
|
Using clear and resize is probably the cleanest way to do it. It would also be more efficient to not use push_back in this case, as it it is likely to trigger a reallocation which will copy all elements. You just resized it; many implementations will make it exactly that size. So, just make each vector in Gout size N+1, and then assign. By default, a vector will start out at size 0. If you push_back an element, it will make space for it, but it grows by doubling. So if you just use push_back, its size will be 1, then 2, 4, 8, 16, 32, 64, etc. Each reallocation will copy all elements into a new vector of the larger size. So if you have some idea how big they are, just call reserve() to reserve some space from the start and prevent reallocations when using push_back. Push_back is close to assignment if it does not trigger a resize. Reserve() and resize() are not the same. Hopefully you know this.
1 2 3
|
Gout.clear(); // empty the vector; size = 0
Gout.resize(N,vector<double>(N+1)); // allocate one extra space in each vector
for(int i=0;i<N;i++) Gout[i][N] = 1; // assignment instead of push_back
|
1 2
|
vector<vector<double>> G1=connectivity( current_combination,M,q2+1,P );
vector<vector<double>> G2=connectivity( circshift_1_dexia(current_combination),M,q1+1,P );
|
This could also be copying vectors since connectivity returns a vector by value. In some cases, the compiler will optimize this out. To avoid this for sure though, you can pass the vector as non-const reference to connectivity rather than returning them. Your code seems a bit over complicated also. The return value of maxweight is a 3-dimensional vector returned by value (which may make a copy of it). You might want to just pass them as non-const references instead of returning them. Also, if you push_back a vector onto another vector, it will generally copy it also, so Qmax may get copied unnecessarily when you push it onto the return vector in addition to when it is returned by value.
It looks like you may be using insert or erase in the middle of a vector. This is really inefficient. Vectors are only efficient for insert or erase at the end, and it is best to call reserve() if you are going to push_back a lot of values. You may be able to re-write it using list if you don't really need random access; with list you lose the subscript operator, but you can still make linear passes through, and save iterators to elements, rather than subscripts.
With some compilers, it can be faster to use pre-increment, rather than post-increment. Prefer ++i to i++ unless you actually need to use the post-increment. They are not the same.
Anyway, vector is going to be horribly slow if you are not compiling with optimization on. With optimization, it is close to built-in arrays. Built-in arrays can be quite slow without optimization on also, but not as bad as vector.
Hopefully, I got all of my code examples right and they are helpful, but I am only up at 7:00am because I am sick and can't sleep, so test carefully if you copy/paste.