It is not uncommon to have vectorized code be slower than a brute force loop. Why?
The word "vectorization" can refer to many different coding paradigms. In a basic example, find the sum of the natural numbers 1 through 100.
n = 1:100;
sum(n)
ans =
5050
N = 100;
S = 0;
for ind = 1:N
S = S + ind;
end
S
S =
5050
Of course, both schemes produce the same end result. One of them generates the set of numbers internally, putting them into memory. Then an internal loop is generated to form the sum. I call that an implicit loop, since you never see the loop itself, but it is there. In the latter case, we have an explicit or external loop.
Will the vectorized version be faster? Well, usually yes. But supose N was 1e9? Or some number large enough, that just to populate that large a fragment of internal memory with these numbers is itself highly CPU intensive. You may even force MATLAB to use virtual memeory, swapping stuff in and out. So there is a point where the explicit loop may be better. (I recently recall an example running of exactly that case, in some recent response I wrote, but I write a LOT of responses...)
Of course, there are many other variations of codes, vectorized and unvectorized, that will gain or not, depending on the problem size. Sometimes it is the dimensionality of the problem that costs you.
For example, suppose I wanted to find all sets of 6 integers that sum to 50? I could write it like this:
tic,
Sets = zeros(0,6);
for n1 = 1:50
for n2 = n1:50
for n3 = n2:50
for n4 = n3:50
for n5 = n4:50
for n6 = n5:50
if (n1 + n2 + n3+ n4+ n5+ n6) == 50
Sets(end+1,:) = [n1, n2, n3, n4, n5, n6];
end
end
end
end
end
end
end
toc
Elapsed time is 0.096587 seconds.
size(Sets,1)
ans =
5427
So we have nested for loop, 6 levels deep. UGH. That actually ran pretty quickly, though if I made the problem a little larger, my computer will still grind to a halt. But it will terminate eventually. Totally unvectorized though.
Or, I could use ndgrid to generate ALL possible combinations of the numbers 1:45. Then isolate the ways they will add up to 50. Something like this:
tic,
elements = int16(1:45);
[N1,N2,N3,N4,N5,N6] = ndgrid(elements,elements,elements,elements,elements,elements);
ind = ((N1 + N2 + N3 + N4 + N5 + N6) == 50) & (N1 <= N2) & (N2 <= N3) & (N3 <= N4) & (N4 <= N5) & (N5 <= N6);
Sets = [N1(ind),N2(ind),N3(ind),N4(ind),N5(ind),N6(ind)];
toc
Elapsed time is 175.219414 seconds.
size(Sets,1)
ans =
5427
Each array will contain 45^6 elements, so approximately 8e9 elements, each of which is a double. (To be a little smart, I did this using int16 arrays.) Now find all combinations of those arrays, where they sum to 50. This scheme I tried on my computer (whcih has a fair amount of RAM) and almost gave up, with all 8 CPUS going full tilt, and my system fan running flat out for about 3 minutes.
Do you see the latter form is massively memory intensive, while the former is massively looped?
Another approach is to use my own partitions code, found on the FEX, where a recursive search is performed.
tic,P6 = partitions(50,1:45,6,6);toc
Elapsed time is 0.296554 seconds.
size(P6,1)
ans =
5427
Again, there are only 5427 solutions there. It is actually slower than the brute force looped approach, but faster than the massive memory solution.
There are other variations of vectorized solutions to problems, surely more than I can count easily, because people call all sorts of things vectorizations. Sometimes, a solution that uses mathematics is a "vectorization". For example, if you want to form the sum of the numbers 1:n, you might just use the formula, known even to Gauss:
N = 100;
N*(N+1)/2
ans =
5050
The point is, vectorized schemes vary widely. They are not always more efficient. Sometimes you may choose a vectorized scheme purely because it looks pretty. I can think of schemes to solve a problem that use tools like intlinprog or lsqlin or backslash, where the solution might then be called a vectorized solution.
What really matters is you understand what the vectorization is doing, and why it may or may not be efficient. Whether it actually gains will often be problem/parameter/size dependent. In the end, you gain when you understand the mathematics, when you understand the limitations of your computer, and when you understand how MATLAB will internally implement the code you write.
