Re: Finding Octave's memory use breakdown

[LachlanA]

Daniel Sebald wrote
> On 04/25/2016 11:31 PM, LachlanA wrote:
>>
>> debug>  whos
>> Variables in the current scope:
>>
>>     Attr Name                  Size                     Bytes  Class
>>     ==== ====                  ====                     =====  =====
>>    a     argn                  4x4                         16  char
> ...
>>          capFactor1         3000x365x31             271560000  double
> ...
>>      f   s                     1x1                  655798080  struct
>>
>> Total is 174126036 elements using 1410586470 bytes
> 
> 64 bit?
> 
> 1410586470 - 174126036 * 8 = 17578182
> 
> or about 1.3% overhead for internal book keeping.  Am I thinking of that 
> correctly?

I thought that these were just the sum of the first and second numeric
columns.  It accounts for the fact that sparse matrices have many more
elements than are stored, and the fact that structures like "s" can be huge
despite having a single element.

I didn't think any of it was a measure of bookkeeping -- but would be really
pleased if it did!


Daniel Sebald wrote
> You are thinking that somehow the act of parsing code is consuming 
> memory?  A possible memory leak?  As I see it, parsing should be a 
> temporary consumption of memory, that eventually gets cleaned up with 
> successive returns to the command line (i.e., end of processing).

It doesn't seem to go up continually like a memory leak would.  The parse
trees don't get deleted after execution.  IIUC, they stay around until the
file is modified, the path is changed, or Octave is terminated; returning to
the command line just causes their timestamps to be checked.

My guess is that the parse trees are usually small -- it would just be nice
to be able to know how small.


Daniel Sebald wrote
> Can we come up with a script to compare across systems?  Something 
> simple that illustrates what seems strange to you?  For example, I'd 
> think that "plot" parses a lot of code, so I've done:
> 
> for i=1:20
>    figure(i);
>    plot(1:5000);
> end
> close all
> 
> and the memory goes from 9.6 MB to 21.1 MB and doesn't come back down 
> with the close all, and whos shows but a single variable.

My guess would be that that is loading FLTK, but I could be wrong.

Thanks for your sleuthing, but it probably isn't worth spending more time on
this.  I think that what I observed was the fact that some "clear"ed memory
isn't being returned to the OS (which only occurred to me during this thread
-- so it has been helpful), possibly combined with forgetting to do whos on
all stack frames...

Thanks to all who replied,
Lachlan



--
View this message in context: 
http://octave.1599824.n4.nabble.com/Finding-Octave-s-memory-use-breakdown-tp4676477p4676508.html
Sent from the Octave - Maintainers mailing list archive at Nabble.com.