RE: Octave memory leak??

[John W. Eaton]

On  2-Sep-1998, (Ted Harding) <address@hidden> wrote:

| If that was the case, I'm curious about the mechanism -- does it mean
| that new copies of the m-files are brought into memory every iteration,
| leaving the old ones there, orphans but still on the books, when this
| happens?

Unless the time-stamp on a .m file is newer than the last time the .m
file was parsed, Octave should not be reading and parsing it again.  The
bug was just a missing call to free() inside the kpathsearch library.

Earlier versions of Octave were using kpathsearch to look up the
locations of the .m files each time they were used, unless
ignore_function_time_stamp was set to 1.  The bug in the kpathsearch
library didn't waste much memory on each call, but because Octave
called on the library a lot, the leak turned out to be significant.

Now the bug in the kpathsearch library (at least the one distributed
with Octave) is fixed.  Also, Octave calls on the library a lot less.
In 2.0.13, the default behavior is for function time stamps to be
checked at most once between the printing of a prompt, which should
speed things up a little too.

jwe