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).
They seem to already have improved it quite a bit in R2009a; here are my results from running your code:
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.
Yair,
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.
wow. that’s a pretty significant unnecessary slowdown. at least this would be easy to catch with the profiler.
Yair-
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.
–Loren
[…] Different performance hotspots can have different solutions: caching, vectorization, internal library functions, undocumented graphics properties, smart property selection, smart function selection, smart indexing, smart parameter selection etc. […]
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):
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:
http://hg.savannah.gnu.org/hgweb/octave/rev/cf8cd43cdeb3
On my laptop with Intel Core 2 Duo @ 2.20G, I see the following:
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:
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.
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:
http://octave.1599824.n4.nabble.com/More-cellfun-related-benchmarks-td3724314.html
@Jordi – thanks. If you have any other comparisons to Octave for any of the other articles here, please do post a comment.
MATLAB 2011b result:
[…] – I found out the reason for the speedup. It is indeed recognition of length specifically. Thanks to @reve_etrange for the […]
MATLAB R2013a result:
The MathWorks don’t seem to be in a rush to optimize this…
This is what happens in R2015b:
The gap is still present
R2016a :/
2017b
Octave 4.2.2
This is an old article, but the issue persists even in 2023.
2023a:
z = mat2cell(1:1e6,1,repmat(1,1,1e6));
f = @() cellfun(‘isempty’,z);
g = @() cellfun(@isempty,z);
a1=timeit(f)
a1 =
0.0053
a2=timeit(g)
a2 =
0.7142
a2/a1
ans =
135.1974