Some time ago I wrote a mostly matlab compatible memory() function for
two main reasons:
- I often work with datasets far bigger than my pc memory and I have to
split them into chunks which just fit into ram.
- I wanted to track down a memory leak that occured in preparing 5.0.
So far I did not think about submitting it to the octave kernel because
it works on linux only. But I just realized that matlabs memory() is
available on windows only. So I think a linux only memory() for octave
The function is octave only code, a single m-file which reads the linux
/proc/pid/statm, /proc/pid/status and /proc/meminfo pseudo files to
retrieve exactly the same information you get with the "top" command.
I use it frequently for more than a year on 64Bit amd64 systems with
kernels 3.2 - 5.5 and have tested a little bit on i386 32Bit systems,
too (Debian & Ubuntu).
But I am not sure if it will work in every situation on 32Bit systems as
memory management and limitations are much more complicated there. Would
it be better to provide it for 64Bit only?
Should a warning or an error be thrown on other architectures?
And there are some compatibility issues with the matlab function.
E.g. naming of fields: Should "MemUsedMATLAB" become "MemUsedOctave" or
should both names be provided?
Matlab's MemAvailableAllArrays and MaxPossibleArrayBytes return the
available memory amount *including swap*. Which renders the system
almost unusable when fully allocated.
So I introduced few new, octave-only fields, e.g.
"RamAvailableAllArrays" which returns the available *ram*, which is what
you really want to know for efficient work. Is this ok in regard to
usability / compatibility?
If you think it is worth the effort, I will start to make the code
suitable for publication and submit it to Savanahs patches. But I will
need some guidance and help for all the work necessary to introduce a
new function to octave: Documentation, compatibility issues, tests etc.
However - the questions remains, wether to introduce a compatible
version to the octave core.
Am 20.04.20 um 13:16 schrieb Andreas Weber:
> Hi Lars,
> please don't reply to an existing thread (audio pkg release) and change
> the topic. This is called "Thread-Hijacking"
> Am 20.04.20 um 13:03 schrieb Lars Kindermann:
>> Some time ago I wrote a mostly matlab compatible memory() function for
> Do you know
> https://github.com/octave-de/macgyver_utils/blob/master/memory.m ?
> -- Andy