memory leaks (simple coding to complex ones)
21 vues (au cours des 30 derniers jours)
Afficher commentaires plus anciens
Hi all,
I am desperate with memory leaks on Matlab coder.
A simple code as this would increase the ram usage of Matlab over time until I’ll have to kill the process or it will simply end itself the process.
close all
clear all
for ii=1:15
eval(strcat('A_',num2str(ii),'=zeros(1,28800);'));
end
i_count=1;
while true
for ii=1:15
eval(strcat('A_',num2str(ii),'=[A_',num2str(ii),'(1,2:end) rand];'))
end
pause (0.001)
i_count=i_count+1;
display(i_count)
end
This is just an example of the main code. My problem isn’t this code, but one build of multiple functions, multiple GUIs, but the idea is the same: a function working over a very very long time (several months). A very long term perspective where only after several hours Matlab’s RAM is over 2 Gb. In the actual code I defined bigger matrix, vector/cells and variables before the smaller ones. Variables NEVER change size during the endless loop. The code is clean (as much as I can think of). Actual sum of size of variables is 43 Mb constant (a file is saved every second with the Whos results), I used sparse matrix I clean and reallocate memory of the exact same size (like figure images of same resolutuion, plot axes and 3d objects, everything is the same size after millions of loops….
But I’m not asking what is wrong with that main code. I’m asking what is wrong with this simple one? A stop of the process will show same size of the files and a clear all will not make the ram go down. I read a lot on the net about this saying you can only restart Matlab (so I have a backup solution to restart Matlab at midnight everyday… but this is patching instead of solving the main problem). Please, any idea is welcome.
(do note that in order for this to work and not have an out of memory problem from java you have to adjust the java heap memory allocation to a bigger value).
0 commentaires
Réponses (2)
Jan
le 30 Mar 2019
Modifié(e) : Jan
le 30 Mar 2019
"The code is clean" - no, it is not clean. You are using the evil eval, which is a desaster for efficient code. Creating variables dynamically by eval is an really bad idea, see TUTORIAL: Why and how to avoid EVAL
Do you really get problems with Java's heap memory with this example? Note that this code does not use any Java resources at all, so the cause of the problem must be somewhere else.
The dynamic allocation of RAM requests memory from the operating system. Overwriting the formerly created arrays gives the memory back to the OS, but it is free'd, when the OS finds the time to do this. Therefore it matters, how you measure the amount of used memory. As long as no other program requests the memory, the OS might mark it as "not free", but releases it as soon, as it is needed elsewhere. This does not mean, that there is a memory leak.
So please clarify, what exactly you call "ram usage of Matlab". This is not uniquely defined.
0 commentaires
Cristian JECU
le 2 Avr 2019
Modifié(e) : Cristian JECU
le 2 Avr 2019
3 commentaires
Jan
le 4 Avr 2019
Without seeing the code, it is impossible to get an educated guess of the cause of your observations.
eval creates variables in an internal look-up table such that the contents can be found dynamically. Variables created by standard code are caught by Matlab's JIT acceleration and the access is much faster. (By the way, variables changing their type are affected also, so don't do this for efficiency.) It is bold guessing, that this look-up table must be reconfigured from time to time or if it exceeds a certain limit. Note that for small look-up tables a linear search is optimal, for larger a binary search, and for tables exceeding the cache size a Bayer-tree might be better. The memory manager is not documented, but it is a well known fact that eval's do not use it efficiently.
Xdata_new = [Xdata_old(2:end) new_time];
I do not know, if this is done effiiciently inplace or if it reserves a new memory block and copies the contents of the old one. In the 2nd case the formerly used memory is given back to the operating system, but the OS decides, when to overwrite it by zeros and release it. So this can be a timing problem.
Voir également
Catégories
En savoir plus sur Logical dans Help Center et File Exchange
Community Treasure Hunt
Find the treasures in MATLAB Central and discover how the community can help you!
Start Hunting!