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