Re: cellfun performance

[Jordi Gutiérrez Hermoso]

2011/8/9 Jordi Gutiérrez Hermoso <address@hidden>:
> 2011/8/8 Rik <address@hidden>:
>> On 08/08/2011 12:39 AM, Jordi Gutiérrez Hermoso wrote:
>
>>> 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.
>
> I stepped through the code a little more carefully, and I can diagnose
> this better now: both the "sin" and @sin ways of passing a function to
> cellfun eventually end up in octave_builtin::do_multi_index_op through
> polymorphic calls, but the function handle one takes longer to get
> there because it first checks things about function handles, whereas
> the "sin" call gets there faster due to the call to
> symbol_table::find_function () that returns a more octave_value
> representation than a function handle.
>
> So the optimisation here should be simple, call a similar function for
> function handles or other kinds of functions, but I cannot find
> something in the Octave API for doing so.

I have pushed the following (and two bad csets that soiled history,
sorry) which seems to eliminate cellfun slowness at least for function
handles to built-in functions:

     http://hg.savannah.gnu.org/hgweb/octave/rev/d1db86336a49

If you can confirm that cellfun is no slower now for function handles
to built-in functions, perhaps we can also backout cset
12931:cefd568ea073 and half of 12932:f951ffdd0133. I was working with
a debug build without -O2 on which I could confirm they were of
comparable speed now, but I didn't rebuild my optimised build to also
check there.

TIA,
- Jordi G. H.