[Octave-bug-tracker] [bug #65669] Cell array construction is memory-intensive

[Petter]

Follow-up Comment #28, bug #65669 (group octave):


> I am guessing that using a memory pool for allocating and deallocating
objects would help mitigate this behavior by preventing such large allocations
in the first place, so that even if Linux retains memory like it does, there
wouldn't be that much to lose. But I can't be certain. There are such object
pool patches in the Octave patch tracker. I used to keep them up to date with
the codebase but haven't used them for a while.

I don't think those patches would help here since the pool is only like 8
objects deep.

I ran:

for i = 1:100000
    mem = memory; mem.mem_used_octave
    a = num2cell(ones(12000));
    clear a
    mem = memory; mem.mem_used_octave
    disp("")
end


and there seem to be no actual problem. Is this more than a reporting
inconsistency?

The freed nodes should be available even though they are not collected by
whoever (glibc, linux?) manages the heap, right? I think there are collection
sweeps.

Each cell element will construct a octave_value object on the heap, so there
are a lot of pointers.



    _______________________________________________________

Reply to this item at:

  <https://savannah.gnu.org/bugs/?65669>

_______________________________________________
Message sent via Savannah
https://savannah.gnu.org/