[Octave-patch-tracker] [patch #9924] Suggestion for a memory() function

[Lars Kindermann]

URL:
  <https://savannah.gnu.org/patch/?9924>

                 Summary: Suggestion for a memory() function
                 Project: GNU Octave
            Submitted by: larskindermann
            Submitted on: Mon 20 Apr 2020 03:20:31 PM UTC
                Category: Core : new function
                Priority: 5 - Normal
                  Status: None
                 Privacy: Public
             Assigned to: None
        Originator Email: 
             Open/Closed: Open
         Discussion Lock: Any

    _______________________________________________________

Details:

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

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?

A very first version of memory.m is attached.

Any comments?




    _______________________________________________________

File Attachments:


-------------------------------------------------------
Date: Mon 20 Apr 2020 03:20:31 PM UTC  Name: memory.m  Size: 7KiB   By:
larskindermann

<http://savannah.gnu.org/patch/download.php?file_id=48881>

    _______________________________________________________

Reply to this item at:

  <https://savannah.gnu.org/patch/?9924>

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