Re: More cellfun related benchmarks

[Jordi Gutiérrez Hermoso]

On 6 August 2011 20:12, Rik <address@hidden> wrote:

> All of this suggests that cellfun should always be called with a
> string argument since it will be faster than the equivalent function
> handle and can potentially be much faster in common instances.
>
> Accordingly, I went ahead and made the change for the core Octave
> functions in this changeset
> (http://hg.savannah.gnu.org/hgweb/octave/rev/cefd568ea073).

I'm very troubled by this change, because it shouldn't be true that a
string should be faster than a function handle. Also, changing all
function handles of cellfun to strings in a way seems like a
regression. Accordingly, I stepped slowly through the code to try to
see what could happen.

My only guess is this: src/DLD-FUNCTIONS/cellfun.cc uses
symbol_table::find_function which finds built-in functions.
Polymorphically, this later turns into a different code path for
built-in functions that seems slightly more efficient. For function
handles, the code path is longer since the polymorphic call does
things like check if the function handle refers to a file (!) on
*each* function evaluation for each element of the cell, plus a couple
more hops in the call stack through a number of polymorphic calls of
octave_value::do_multi_index_op.

If there is a way to find a better code path for built-in function
handles that follows the one for strings, it shouldn't be necessary to
remove function handles as arguments to cellfun.

This was all on a debug build without -O2 so I could step through the
code, so this may be a completely wrong guess as the optimised code
could take a widely different code path. I did try to debug the
optimised code, but the jumping around the source code seemed quite
erratic.

- Jordi G. H.