Re: cellfun calling style

[John W. Eaton]

On 20-Sep-2011, Rik wrote:

| The two calling forms show equivalent performance (@ function handle was
| still 2.8% slower than raw string) when the function is not one of the
| expedited functions built in to cellfun.  If the function is builtin the
| performance gain is over 100X.  Thus, cellfun ("isempty", ...) is 112X
| faster than cellfun (@isempty, ...).  I had a slight preference for setting
| the convention to use the quoted form since it will pick up the accelerated
| cases where possible.  I foresee less experienced programmers trolling the
| code, discovering the @ function handle convention, using it regardless of
| the function involved, and thereby missing big performance gains.  In
| particular, the "isclass" syntax doesn't get used much and is far faster
| than an equivalent functional form such as @ischar or @iscell.
| 
| As I said, I have a preference for the quoted form right now, but I don't
| feel religious about it and if you want to change all the non-accelerated
| functions over to function handles that would be okay.  Another idea would
| be to code the cellfun function to recognize both the string and function
| handle forms of accelerated functions.  The current setup is easy as it
| essentially uses a strcmp against the passed in string.  It seems like it
| would be possible to get the name of the function as a string by looking up
| the function handle in the symbol table.  Once you have the name of the
| function you could use the same string equality test to see whether to
| accelerate it or not.  I'm thinking of line 374 in cellfun.cc
| 
| octave_value f = symbol_table::find_function (func.function_value ()
|                                                          -> name ());

We probably don't want to do that because I think it will screw up
cases where people actually do want to use the function handle for
purposes of finding the right overloaded function to call.  For
example, if you make the call

  cellfun (@isempty, some_cell_array)

when there is a subfunction or private function or class member
function with the same name as some generic function in the search
path you will definitely expect Octave to call the overloaded
function, not the generic one or the accelerated one that you would
get if you called cellfun with "isempty" instead of @isempty.

Currently, I see a bug with function resolution for this sort of
thing regarding class member functions (at least), but I'm working on
fixing it.

Or, maybe it would be possible to determine that there is no
overloaded function to call, and in that case we could handle known
functions internally instead of by dispatching through the function
handle.  I haven't looked in detail, so I'm not sure how hard that
would be or whether the performance gain would still be large.

Either way, maybe it should be more clearly documented that there is a
special list of functions that are handled internally and therefore
get better performance in the case that you just want the default
generic function to be applied.

jwe