Re: OCTAVE_LOCAL_BUFFER

[Jaroslav Hajek]

On Thu, Dec 4, 2008 at 6:25 PM, Jaroslav Hajek <address@hidden> wrote:
> hi,
>
> currently, OCTAVE_LOCAL_BUFFER is implemented using std::vector, which
> has several drawbacks:
> 1. often doesn't work with bool (std::vector<bool> is not a proper container)
> 2. is not local (always on heap)
> 3. always includes the full <vector> header (no big deal, but still)
>
> please see the attached patch that aims to overcome the problem.
> The idea is that if dynamic arrays are detected, the buffer is made on
> stack if the requested size is small enough, otherwise a simplistic
> wrapper class is used that ensures proper destruction.
> Note that this is made against a little older snapshot and so may not
> apply cleanly.
>
> regards
>
> --
> RNDr. Jaroslav Hajek
> computing expert
> Aeronautical Research and Test Institute (VZLU)
> Prague, Czech Republic
> url: www.highegg.matfyz.cz
>

OK, the new code for OCTAVE_LOCAL_BUFFER is uploaded. It appears that
octave_fcn_handle::load_binary relied on the old behaviour of using
std::vector (which always default-initializes elements). I believe
that OCTAVE_LOCAL_BUFFER was not intended to be initialized, so I
fixed the offending code.

The current state is as said above: a buffer < 8K is allocated on the
stack (if dynamic stack arrays are supported), otherwise via normal
new[] allocation.
I'm not sure 8K is the best constant, but stack is a very limited
resource, and its overflow is typically unrecoverable, so I tried to
be conservative...

There is a more sophisticated optimization of local buffers possible.
Since they have a FIFO semantics, it is possible to allocate big
chunks (say, 16 MB) in a stack-like manner and serve local buffers
from them. Obstacks from the GNU C library are based on the same idea
(except that using obstacks would be an overkill, because we would
need only a small subset of their functionality).

opinions?

-- 
RNDr. Jaroslav Hajek
computing expert
Aeronautical Research and Test Institute (VZLU)
Prague, Czech Republic
url: www.highegg.matfyz.cz