If performance is a major factor you should avoid using cells, loops or cellfun/arrayfun. It's usually much quicker to use a vector operation (assuming this is possible).

The code below expands on Werner's add example with standard array loop and array operations.

The results are:

• Cell Loop Time - 0.1679
• Cellfun Time - 2.9973
• Loop Array Time - 0.0465
• Array Time - 0.0019

Code:

nTimes = 1000;
nValues = 1000;
myCell = repmat({0},1,nValues);
output = zeros(1,nValues);

% Basic operation
tic;
for k=1:nTimes
  for m=1:nValues
    output(m) = myCell{m} + 1;
  end
end
cell_loop_timeAdd=toc;    
fprintf(1,'Cell Loop Time %0.4f\n', cell_loop_timeAdd);

tic;        
for k=1:nTimes
  output = cellfun(@(in) in+1,myCell);
end
cellfun_timeAdd=toc;
fprintf(1,'Cellfun Time %0.4f\n', cellfun_timeAdd);


myData = repmat(0,1,nValues);
tic;
for k=1:nTimes
  for m=1:nValues
    output(m) = myData(m) + 1;
  end
end
loop_timeAdd=toc;
fprintf(1,'Loop Array Time %0.4f\n', loop_timeAdd);

tic;
for k=1:nTimes
    output = myData + 1;
end
array_timeAdd=toc;
fprintf(1,'Array Time %0.4f\n', array_timeAdd);

Cellfun and arrayfun are generally much slower than simple loop. Their main usecase is to simplify code where performance is not an issue. Better alternative is vectorization which is both fast and concise. (For gpuArrays, arrayfun is faster but that is a special case).

For loops are usually faster than arrayfun or cellfun, as the for loop does not need to invoke the function handle each time. The for loop also has opportunities for optimizations between statements that the arrayfun or cellfun would not have. arrayfun() or cellfun() can be faster to write the code for, as they are a higher level concept. Not always, though: some of the twists one has to go through to create the behaviour as an anonymous function can be messy.

Looking around on StackOverflow, it seems like this is recognized behavior. But that doesn't mean there aren't cases where arrayFun can perform better.

On my machine, my times are roughly twice yours for your code. But consider this example instead:

x = gpuArray(rand(100,100,3));
tic
    z = arrayfun(@(x) x^2, x);
toc

z = gpuArray(zeros(length(x),1));
tic
    for i=1:length(x(:))
        z(i) = x(i).^2;
    end
toc

Elapsed time is 0.011370 seconds.
Elapsed time is 17.763806 seconds.

Arrayfun's assumptions that allow for parallel code leads to a huge jump in performance in that use case (mostly because the for loop approach isn't great for running on the GPU). Not sure if it's even a fair comparison, frankly.

On Matlab Central, one poster suggests avoiding arrayfun if you're not planning on using a GPU: https://www.mathworks.com/matlabcentral/answers/144344-in-my-code-arrayfun-slower-than-for-loop

With the exception of being on a GPU, arrayfun will most likely often be slower than a for-loop and harder to read. It's just a less flexible more complex for-loop.

Personally, I'd recommend against it at all cost unless you're targeting a GPU.

Obviously, my for loop on a GPU is much slower, and the GPU arrayfun call is roughly the same speed as your "direct" method on my machine. For more complex examples, I'd expect the GPU approach to really show its stuff.

Tell us once you tried it :)

Well, I got a few minutes at the airport. Try this in your comparison: tic ; s = cellfun('length', t) ; v = cumsum(s) ; e_cw = double([t{:}]) ; e_cw = [e_cw; e_cw(2:end),0] ; e_cw(2,v) = e_cw(1,[0,v(1:end-1)]+1) ; toc (your move, Andrei ;) )

sizes = cellfun('size', cellArr, 1); Using the CHAR vector arguments is mentioned in the documentation as "backward compatibility". This calling style is the only one, in which cellfun is faster than a simple loop.

It really depends on what you call 'performance' :)

If you mean minimum execution time, well, sometimes *fun are faster (for example, cellfun('isempty', ...); (yes, string argument!) for sure beats the loop version). Sometimes a loop is faster. If you're on a Matlab version < 2006, go for the *fun functions by default. If you're on anything more recent, go for the loops by default. You'll still always have to profile to find out which one's faster.

As noted by Amro, if you have a GPU capable of doing FP arithmetic, and a recent version of Matlab that supports GpGPU, then a call to arrayfun for gpuArray inputs will be massively-parallelized. However, no general statements can be made regardnig execution time; for smaller arrays, or absolutely humungous ones, the overhead of copying everything over to the GPU might undo any benefit of parallelizing the computations, so...profiling is really the only way to know for sure.

If you mean minimum coding time, then I'd say it's usually faster to code in terms of *fun as long as the operations are simple. For anything complex it's usually better to go for the loop.

If you mean optimum readability and thus minimum time required for maintenance and implementation of changes in a professional context, for sure, go for the loop.

At this point in time, there's not really a clear-cut simple answer to your question :)

You can get the idea by running other versions of your code. Consider explicitly writing out the computations, instead of using a function in your loop

tic
Soln3 = ones(T, N);
for t = 1:T
    for n = 1:N
        Soln3(t, n) = 3*x(t, n)^2 + 2*x(t, n) - 1;
    end
end
toc

Time to compute on my computer:

Soln1  1.158446 seconds.
Soln2  10.392475 seconds.
Soln3  0.239023 seconds.
Oli    0.010672 seconds.

Now, while the fully 'vectorized' solution is clearly the fastest, you can see that defining a function to be called for every x entry is a huge overhead. Just explicitly writing out the computation got us factor 5 speedup. I guess this shows that MATLABs JIT compiler does not support inline functions. According to the answer by gnovice there, it is actually better to write a normal function rather than an anonymous one. Try it.

Next step - remove (vectorize) the inner loop:

tic
Soln4 = ones(T, N);
for t = 1:T
    Soln4(t, :) = 3*x(t, :).^2 + 2*x(t, :) - 1;
end
toc

Soln4  0.053926 seconds.

Another factor 5 speedup: there is something in those statements saying you should avoid loops in MATLAB... Or is there really? Have a look at this then

tic
Soln5 = ones(T, N);
for n = 1:N
    Soln5(:, n) = 3*x(:, n).^2 + 2*x(:, n) - 1;
end
toc

Soln5   0.013875 seconds.

Much closer to the 'fully' vectorized version. Matlab stores matrices column-wise. You should always (when possible) structure your computations to be vectorized 'column-wise'.

We can go back to Soln3 now. The loop order there is 'row-wise'. Lets change it

tic
Soln6 = ones(T, N);
for n = 1:N
    for t = 1:T
        Soln6(t, n) = 3*x(t, n)^2 + 2*x(t, n) - 1;
    end
end
toc

Soln6  0.201661 seconds.

Better, but still very bad. Single loop - good. Double loop - bad. I guess MATLAB did some decent work on improving the performance of loops, but still the loop overhead is there. If you would have some heavier work inside, you would not notice. But since this computation is memory bandwidth bounded, you do see the loop overhead. And you will even more clearly see the overhead of calling Func1 there.

So what's up with arrayfun? No function inlinig there either, so a lot of overhead. But why so much worse than a double nested loop? Actually, the topic of using cellfun/arrayfun has been extensively discussed many times (e.g. here, here, here and here). These functions are simply slow, you can not use them for such fine-grain computations. You can use them for code brevity and fancy conversions between cells and arrays. But the function needs to be heavier than what you wrote:

tic
Soln7 = arrayfun(@(a)(3*x(:,a).^2 + 2*x(:,a) - 1), 1:N, 'UniformOutput', false);
toc

Soln7  0.016786 seconds.

Note that Soln7 is a cell now.. sometimes that is useful. Code performance is quite good now, and if you need cell as output, you do not need to convert your matrix after you have used the fully vectorized solution.

So why is arrayfun slower than a simple loop structure? Unfortunately, it is impossible for us to say for sure, since there is no source code available. You can only guess that since arrayfun is a general purpose function, which handles all kinds of different data structures and arguments, it is not necessarily very fast in simple cases, which you can directly express as loop nests. Where does the overhead come from we can not know. Could the overhead be avoided by a better implementation? Maybe not. But unfortunately the only thing we can do is study the performance to identify the cases, in which it works well, and those, where it doesn't.

Update Since the execution time of this test is short, to get reliable results I added now a loop around the tests:

for i=1:1000
   % compute
end

Some times given below:

Soln5   8.192912 seconds.
Soln7  13.419675 seconds.
Oli     8.089113 seconds.

You see that the arrayfun is still bad, but at least not three orders of magnitude worse than the vectorized solution. On the other hand, a single loop with column-wise computations is as fast as the fully vectorized version... That was all done on a single CPU. Results for Soln5 and Soln7 do not change if I switch to 2 cores - In Soln5 I would have to use a parfor to get it parallelized. Forget about speedup... Soln7 does not run in parallel because arrayfun does not run in parallel. Olis vectorized version on the other hand:

Oli  5.508085 seconds.