[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: octave memory allocation problem ?
From: |
Joao Cardoso |
Subject: |
Re: octave memory allocation problem ? |
Date: |
Wed, 26 Apr 1995 00:27:06 +0200 (MET DST) |
Hi,
I APOLOGIZE.
*** Matlab's "load" does not work as I said. ***
In the process of converting my "Matlab v4.0 for Windows" files to Octave
I get confused (to be kind with myself...).
Now, about the memory leak, here is a description of the problem I found.
It seems to be related with function invocation (at least).
My system is a SCO 2.0., "i486-unknown-sco3.2v4.0"
I did not run the tests when I build octave, as I have no DejaGnu.
I also notice this problem with recursion, using the supplied recursion-1.m
in the distribution test/recursion directory.
The original problem:
octave
Octave, version 1.1.1.
Copyright (C) 1992, 1993, 1994, 1995 John W. Eaton.
This is free software with ABSOLUTELY NO WARRANTY.
For details, type `warranty'.
octave:1> type popo
popo is a user-defined function
function a = popo (file)
eval (["load ", file, ";"])
a = b;
endfunction
octave:2> system("ps -l"| fgrep octave")
20 S 200 335 298 0 26 20 8fc 58e 748 f014abfa p1
0:00 octave
octave:3> b=rand(100); ^^^
octave:4> system("ps -l | fgrep octave")
20 S 200 335 298 1 26 20 8fc 58e 828 f014a2fa p1
0:01 octave
octave:5> save caca b ^^^
octave:6> clear
octave:7> system("ps -l | fgrep octave")
20 S 200 335 298 1 26 20 8fc 58e 748 f014a2fa p1
0:03 octave
octave:8> a=popo("caca"); ^^^
octave:9> system("ps -l | fgrep octave")
20 S 200 335 298 5 26 20 8fc 58e 872 f014a2fa p1
0:06 octave
octave:10> clear -x ^^^
octave:11> system("ps -l | fgrep octave")
20 S 200 335 298 1 26 20 8fc 58e 872 f014a2fa p1
0:06 octave
octave:12> clear * ^^^
octave:13> system("ps -l | fgrep octave")
20 S 200 335 298 1 26 20 8fc 58e 792 f014a2fa p1
0:06 octave
octave:14> clear -x ^^^
octave:15> system("ps -l | fgrep octave")
20 S 200 335 298 1 26 20 8fc 58e 792 f014a2fa p1
0:06 octave
^^^
octave:16> for i=1:10; a=popo("caca"); clear -x *;system("ps -l | fgrep
octave"); end
20 S 200 335 298 81 26 20 8fc 58e 836 f014a2fa p1
0:09 octave
20 R 200 335 298 62 91 20 8fc 58e 884 p1
0:12 octave
20 R 200 335 298 40 80 20 8fc 58e 932 p1
0:14 octave
20 R 200 335 298 81 100 20 8fc 58e 996 p1
0:17 octave
20 R 200 335 298 81 100 20 8fc 58e1040 p1
0:19 octave
20 R 200 335 298 79 99 20 8fc 58e1084 p1
0:22 octave
20 R 200 335 298 58 89 20 8fc 58e1128 p1
0:24 octave
20 R 200 335 298 41 80 20 8fc 58e1172 p1
0:27 octave
20 R 200 335 298 81 100 20 8fc 58e1216 p1
0:30 octave
20 R 200 335 298 81 100 20 8fc 58e1260 p1
0:32 octave
^^^^
octave:18> who -l
Notice that memory is incremented in steps of 44 pages, occasionally more.
With an array with the double size, rand(100,200) the behavior is the same, as
well as with an array of 500x500 (a five Megabyte file). This means that the
problem is not related with file size, but with function invocation.
The amount of memory grabbed and not released depends on what is called:
octave:1> system("ps -l | fgrep octave")
20 S 200 923 298 3 26 20 8fc 58e 676 f014933a p1
0:00 octave
octave:2> for i=1:5000; po1(i);end
octave:3> system("ps -l | fgrep octave")
20 R 200 923 298 15 67 20 8fc 58e 764 p1
0:28 octave
octave:5> type po1 ^^^
po1 is a user-defined function
function y = po1 (x)
y = x;
endfunction
With
octave:5> type po1
po1 is a user-defined function
function y = po1 (x)
y = 1;
endfunction
we have the same behavior, as well as with
function po1 ()
endfunction
Now: is this a problem, a feature, a bug, something we can live with, a problem
with my system libraries, or what?
Again, my apologies,
Joao Cardoso
INESC
R. Jose Falcao 110
4000 PORTO
PORTUGAL
e-mail: address@hidden
tel: + 351 2 2094300
fax: + 351 2 2008487
- octave memory allocation problem ?, Ludger Leushacke, 1995/04/19
- octave memory allocation problem ?, Joao Cardoso, 1995/04/19
- Re: octave memory allocation problem ?, John Eaton, 1995/04/20
- Re: octave memory allocation problem ?, John Eaton, 1995/04/20
- Re: octave memory allocation problem ?,
Joao Cardoso <=
- Re: octave memory allocation problem ?, John Eaton, 1995/04/27
- Re: octave memory allocation problem ?, John Eaton, 1995/04/27
- Re: octave memory allocation problem ?, John Eaton, 1995/04/28