Re: deprecated use of octave_allocator

[Andreas Weber]

Am 16.01.2015 um 19:13 schrieb John W. Eaton:
> On 01/16/2015 08:26 AM, Andreas Weber wrote:
>> Dear all,
>>
>> since cset a35d381e22b0 from 2011 USE_OCTAVE_ALLOCATOR is undefined per
>> default. The help text for this configure switch:
>>
>> "--enable-octave-allocator: use the obsolete octave_allocator class for
>> many of Octave's objects (mostly octave_value types). You probably do
>> NOT want to enable this feature."
>>
>> On the project page http://wiki.octave.org/Projects under Numerical it's
>> listed as:
>> "Use octave_allocator for memory management in Array classes once g++
>> supports static member templates."
>>
>> What is the intended use for octave_allocator? Should new code (such as
>> audiodevinfo.cc in line 648 and 554) use the DECLARE_OCTAVE_ALLOCATOR
>> and DEFINE_OCTAVE_ALLOCATOR macros?
> 
> The original idea was to improve performance by having a special
> allocator that would make one large allocation with operator new and
> then split it up into smaller objects and manage the pool.  I'm not sure
> that the small increase in performance (if any) justified the added
> complexity.

I tried to benchmark the "--enable-octave-allocator" option. If enabled
I get

configure: WARNING: Using atomic reference counting.
configure: WARNING: Thread-safe behavior is not guaranteed unless the
configure: WARNING: octave_allocator class is also disabled.

Then I run "time make check"

on the built with default configure flags:
real    6m20.855s
user    5m29.124s
sys     0m48.276s

and the built with "--enable-octave-allocator"
real    6m16.529s
user    5m29.368s
sys     0m47.540s

I also tried to trigger the allocation this way:
default built:
./run-octave --no-gui -q -f --eval "tic; a=3(ones(1e3,1e3)); toc;"
Elapsed time is 0.00732994 seconds.

built with "--enable-octave-allocator":
./run-octave --no-gui -q -f --eval "tic; a=3(ones(1e3,1e3)); toc;"
Elapsed time is 0.00735903 seconds.

So for me it looks like there isn't a performance difference, or my
benchmark experiment is wrong.

-- Andy