Re: cellfun calling style

[Rik]

On 09/20/2011 10:00 AM, address@hidden wrote:
> Message: 6
> Date: Mon, 19 Sep 2011 20:20:44 -0500
> From: Jordi Guti?rrez Hermoso <address@hidden>
> To: Octave Maintainers List <address@hidden>
> Subject: Rik: cellfun(@foo, ...) or cellfun("foo", ...)
> Message-ID:
>       <address@hidden>
> Content-Type: text/plain; charset=UTF-8
>
> As I've been doing the last couple of merges of stable to default,
> I've been running into the issue that the default branch had calls of
> the form cellfun("foo", ...) while the stable branch had cellfun(@foo,
> ...). Following changeset 12949:d1db86336a49, these two no longer show
> a difference of performance for me, while the latter has the advantage
> of being more "semantic", plus I think it will be more easy to
> optimise on the C++ side of things if we ever change our
> implementation of function handles. Following that, I have been
> performing the merges favouring the @foo style from the stable branch.
>
> Rik, I just want to confirm that you think this is ok. As I recall,
> you tested both forms and found no further performance penalty for
> @foo over "foo".
9/20/11

Jordi,

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 ());

Just a thought,
Rik