Re: deprecated use of octave_allocator

[John W. Eaton]

On 01/17/2015 12:10 PM, Andreas Weber wrote:
> 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.

OK, now I remember that this is the reason that we disabled the custom 
allocator by default.  You could probably find more details about the 
decision if you search the list archives around the time when the 
configure option was added.

> 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.

I don't think you are going to get useful data from just one simple 
operation.  A better test might be to compare the time it takes to run 
the full test suite.  That will create many objects, not just a few.

jwe