cellfun – undocumented performance boost

Matlab’s built-in cellfun function has traditionally enabled several named (string) processing functions such as ‘isempty’. The relevant code would look like this:

data = cellfun('isempty',cellArray);

In recent years, newer Matlab releases has added support for function handles, so the previous code snippet can now be written as follows:

data = cellfun(@isempty,cellArray);

The newer function-handle format is “cleaner” and more extensive than the former format, accepting any function, not just the limited list of pre-specified processing function names (‘isreal’, ‘islogical’, ‘length’, ‘ndims’, ‘prodofsize’). Some have even reported that the older format has limitations vis-a-vis compilation etc.

All this is well known and documented. However, it turns out that, counter-intuitively (and undocumented), the older format is actually much faster than the newer format for those pre-specified processing function names. The reason appears to be that ‘isempty’ (as well as the other predefined string functions) uses specific code-branches optimized for performance:

>> c = mat2cell(1:1e6,1,repmat(1,1,1e6));
>> tic, d=cellfun('isempty',c); toc
Elapsed time is 0.115583 seconds.
>> tic, d=cellfun(@isempty,c); toc
Elapsed time is 7.493989 seconds.

Perhaps a future Matlab release will improve cellfun’s internal code, to check for function-handle equality to the optimized functions, and use the optimized code branch if possible. When I posted this issue today as a correction to a reader’s misconception, Matlab’s Loren Shure commented as follows:

We could improve cellfun to check function handles to see if they match specified strings. Even then MATLAB would have to be careful in case the user has overridden the built-in version of whatever the string points to.

While this comment seems to imply that the performance boost feature will be maintained and possibly improved in future releases, users should note that this is not guarantied. One could even argue that future code optimizations would be applied to the new (function-handle) format rather than the old string format. The performance pendulum might also change based on user platform. Therefore, users for whom performance is critical should always test both versions on their target system: ‘isempty’ vs. @isempty etc. (note that the corresponding function for ‘prodofsize’ is @numel).

Related posts:

  1. Performance: scatter vs. line In many circumstances, the line function can generate visually-identical plots as the scatter function, much faster...
  2. Preallocation performance Preallocation is a standard Matlab speedup technique. Still, it has several undocumented aspects. ...
  3. datestr performance Caching is a simple and very effective means to improve code performance, as demonstrated for the datestr function....
  4. Datenum performance The performance of the built-in Matlab function datenum can be significantly improved by using an undocumented internal help function...
  5. Array resizing performance Several alternatives are explored for dynamic array growth performance in Matlab loops. ...
  6. Matrix processing performance Matrix operations performance is affected by internal subscriptions in a counter-intuitive way....

Categories: Medium risk of breaking in future versions, Stock Matlab function, Undocumented feature

Tags: , ,

Bookmark and SharePrint Print

12 Responses to cellfun – undocumented performance boost

  1. Ashish Sadanadnan says:

    They seem to already have improved it quite a bit in R2009a; here are my results from running your code:

    >> c = mat2cell(1:1e6,1,repmat(1,1,1e6));
    >> tic, d=cellfun(‘isempty’,c); toc
    Elapsed time is 0.032880 seconds.
    >> tic, d=cellfun(@isempty,c); toc
    Elapsed time is 0.563284 seconds.

    • Ashish – actually your results show a factor of 17 between the slower @isempty and the faster ‘isempty’, consistent with the results I posted above (my reported factor of 65 is almost the same order of magnitude as 17, and may be due to external platform-dependent factors).

      The absolute values of the results of course depend on the platform: my results were for a run-down heavily-loaded laptop… The important thing here is the factor between @isempty and ‘isempty’ – not the absolute values. And a factor of 17 is still high enough to be taken into consideration in a performance-critical application.

    • Ashish Sadanadnan says:

      I wasn’t disputing your results. Just wanted to show that the factor has improved significantly in newer version (65 to 17). Of course, 17 times faster is still very significant as you pointed out.

      - Ashish.

  2. Naor says:

    wow. that’s a pretty significant unnecessary slowdown. at least this would be easy to catch with the profiler.

  3. Loren S says:


    As I noted to you on my blog, MATLAB doesn’t convert from FH to string method because the user might have overridden whatever the method, e.g., isempty. MATLAB could, at runtime, see if it’s overridden, and if not, call the optimized version. But it can’t do that blindly without risk of wrong answers.


  4. Pingback: datestr performance | Undocumented Matlab

  5. tdc says:

    I know this is old, but I just noticed it gets even worse if you use the other way of calling cellfun (which I’ve been using a lot):

    >> c = mat2cell(1:1e6,1,repmat(1,1,1e6));
    >> tic, d=cellfun('isempty',c); toc
    Elapsed time is 0.034638 seconds.
    >> tic, d=cellfun(@isempty,c); toc
    Elapsed time is 0.859156 seconds.
    >> tic, d=cellfun(@(x) isempty(x),c); toc
    Elapsed time is 7.961039 seconds.
    • I looked at your example, and I noticed that in Octave we hadn’t quite optimised this as much as possible. I went ahead and committed a change to fix this:


      On my laptop with Intel Core 2 Duo @ 2.20G, I see the following:

      octave:1> c = mat2cell(1:1e6,1,repmat(1,1,1e6));
      octave:2> tic, d=cellfun('isempty',c); toc
      Elapsed time is 0.0171831 seconds.
      octave:3> tic, d=cellfun('isempty',c); toc
      Elapsed time is 0.0182698 seconds.
      octave:4> tic, d=cellfun('isempty',c); toc
      Elapsed time is 0.0223808 seconds.
      octave:5> tic, d=cellfun(@isempty,c); toc
      Elapsed time is 0.0193319 seconds.
      octave:6> tic, d=cellfun(@isempty,c); toc
      Elapsed time is 0.01612 seconds.
      octave:7> tic, d=cellfun(@isempty,c); toc
      Elapsed time is 0.019449 seconds.

      This should be part of our 3.6 release that should happen very soon!

      Sadly, your preferred method of calling cellfun cannot be easily optimised:

      octave:8> tic, d=cellfun(@(x) isempty(x),c); toc
      Elapsed time is 0.924903 seconds.
      octave:9> tic, d=cellfun(@(x) isempty(x),c); toc
      Elapsed time is 0.873197 seconds.
      octave:10> tic, d=cellfun(@(x) isempty(x),c); toc
      Elapsed time is 0.875425 seconds.

      Note that Octave still is single-threaded, so this does not benefit from any parallelisation right now. There’s work to build parallelisation into Octave, so perhaps we can see more dramatic speedups in the future.

  6. This is very interesting. Our independent implementation of cellfun in Octave actually behaves very similarly! However, I did optimise it to check function handles for built-in string cases.

    We have a thread about it:


  7. damayi says:

    MATLAB 2011b result:

    >> c = mat2cell(1:1e6,1,repmat(1,1,1e6));
    >> tic, d=cellfun('isempty',c); toc
    Elapsed time is 0.032773 seconds.
    >> tic, d=cellfun(@isempty,c); toc
    Elapsed time is 2.100385 seconds.
    >> 2.100385/0.032773
    ans =
  8. Pingback: How to compute effectively string length of cell array of strings | PHP Developer Resource

Leave a Reply

Your email address will not be published. Required fields are marked *


<pre lang="matlab">
a = magic(3);