Even more interesting is the fact, that a event callback, thrown in .NET and caught in Matlab is slower when it’s an pure function handle. It’s marginal but visible and contrary to your example above, where you state, that all anonymous function calls should be replaced by non-anonymous ones if possible.
.

‘DataIsReady’ is a .NET Framework 4.5 (C#) event. I’m at Matlab 2019b @ windows 10.

% somewhere in a handle class
lis = addlistener(evnt, 'DataIsReady', @obj.onSerialBytesAvailableNet);

...
function onSerialBytesAvailableNet(obj, src, evnt)
     obj.cnt = obj.cnt + 1;
end

vs

% somewhere in a handle class
lis = addlistener(evnt, 'DataIsReady', @(src,evnt)obj.onSerialBytesAvailableNet(src,evnt)); % faster than the rest!
...
function onSerialBytesAvailableNet(obj, src, evnt)
     obj.cnt = obj.cnt + 1;
end

Profiler times:
…j.onSerialBytesAvailableNet(src,evnt) 40807 8.369 s 0.220 s
…nSerialBytesAvailableNet(varargin{:}) 38265 8.407 s 0.347 s

Looks like the addlistener calls the function with varargin{:} when a non-anonymous function is used. I don’t know if that’s special for .NET events or default, but it’s more than 50 % slower in my case.
I know, there is a big number of function calls, and probably not worth mentioning or impacting performance but just figured that out and wanted to hear you comments 🙂

Thanks

@Alex – there is no immediate answer. If you want me to look at your specific code, then email me (altmany at gmail) for a dedicated consulting session.

@(hObject,eventdata)CAEQE('testListBox1_Callback',hObject,eventdata,guidata(hObject))

to

@testListBox1_Callback

inside of my main code.
But in my case it won’t work to get the Callback faster. Can you help?

Alex

@Yair – there are probably many variants I haven’t tested. If I have a function used internally by a single class, then I fully agree with you. However, the exercise here was to create a function handle that forwards its arguments to a method of a class while passing an instance of that class as the first argument. And I fail to see how your suggestion could be used in this scenario, or am I misunderstanding you?

You are missing one important variant, that I expect to be the fastest of all: @plus where plus(obj,x) is a sub-function in the same class file as the main class, but implemented as a separate sub-function rather than a class method. This avoids the two most important method-invocation performance hotspots: anonymous functions and class methods. For any performance-critical code that is repeatedly invoked in class methods, I often use such sub-functions (or standalone procedural functions).

I finally ran a simple benchmark (on OS X 10.10.5) to support my argument. It also very nicely shows the performance improvements in R2015b.

In the benchmark obj is an instance of a custom polynomial class and x is a double scalar. The work done in the plus method is minor, so the performance is dominated by the function/method call overhead. Every run consists of a thousand invocations of the “function handle” created before the loop.

Results after 10 runs (in 84.13s) on MATLAB R2015a:

| Variant                  | Average |    Best |   Worst |
| @(x) obj.plus(x)         |   2.08s |   2.04s |   2.31s |
| @obj.plus                |   2.09s |   2.05s |   2.24s |
| @(x) plus(obj, x)        |   1.72s |   1.70s |   1.75s |
| MethodHandle(obj, @plus) |   1.76s |   1.73s |   1.80s |

Results after 10 runs (in 47.81s) on MATLAB R2015b:

| Variant                  | Average |    Best |   Worst |
| @(x) obj.plus(x)         |   1.28s |   1.26s |   1.29s |
| @obj.plus                |   1.29s |   1.28s |   1.33s |
| @(x) plus(obj, x)        |   0.86s |   0.84s |   0.89s |
| MethodHandle(obj, @plus) |   0.91s |   0.90s |   0.92s |

The last line was initially a silly experiment, that turned out to be surprisingly fast. It is a class that holds an object instance and a function handle and overrides the subsref method to provide a function-handle-like interface. In the end MethodHandle(obj, @method) should behave like @(varargin) method(obj, varargin{:}).

@Chris – this is a limitation of GUIDE. You can modify the callbacks programmatically in your GUIDE-generated m-file (Main_Program.m), for example in the OpeningFcn(). In this function, all the other subfunctions of the m-file are in scope and so you can directly set the relevant callbacks to their direct function handles.

@(hObject,eventdata)Main_Program('button_name_Callback',hObject,eventdata,guidata(hObject))

I tried changing this to @button_name_Callback, but it seems that where it’s evaluating the callbacks, functions like button_name_Callback inside Main_Program are out of scope. Is this a limitation of GUIDE, or do you know if there some way I can make this work?

One more note about the performance implications of changing @(h, e) obj.tableDeletedCallbackFcn(e) to @obj.tableDeletedCallbackFcn (example from the article):

I fail to see why this should improve performance at all. My doubts stem from the fact that the latter looks like a simple function handle, but in fact turns out to be an anonymous function handle. MATLAB R2015b prints: @(varargin)obj.tableDeletedCallbackFcn(varargin{:}). So this only saves us from having to write out the arguments. And calling functions (a function that offers a glimpse at the internal representation of function handles) on that also confirms the type to be “anonymous”. From a conceptual point of view it has to be that way, because anonymous function handles are the only type capable of storing some workspace alongside the function handle. And, well, there’s this obj that needs to be stored somewhere.

I have to admit, that I haven’t benchmarked theses different versions, though. So maybe structurally there should be no big difference, but in fact there is.

If multiple arguments were involved, like in myCallback(a, b, c), and arguments had different type, there would be even more possibilities for what gets called. E.g., if c had a higher precedence than the other two arguments, then the method from the class of c would be picked, if available. (See the InferiorClasses attribute used with classdef and also “Class Precedence” in the MATLAB documentation. The concept is called multiple dispatch, which is not a very common programming language feature, but makes a lot of sense in an environment geared towards scientific computing.)

These subtleties are probably not very relevant in the context of callbacks, but it is good to be aware of them nonetheless.