Why/How does MATLAB run faster when the workspace is full of variables?

26 visualizaciones (últimos 30 días)
I've been running some finite element code written for MATLAB that takes up at least 40 variables and near 100 mb of memory in the workspace. This code takes anywhere from 28 to 32 minutes to run.
However, I noticed that if I don't clear the workspace with the CLEAR command and just run the new case, MATLAB runs the code in about 15 to 18 minutes! However, if I do clear the workspace with the CLEAR command and run a new case, it takes about 28 to 32 minutes to finish again!
I'm proficient in MATLAB but not an expert. Can someone enlighten me on why this happens and if there is some "trick" that I can exploit to make MATLAB run even faster?
I am using a Dell Precision T1500 with an i5 (64bit) processor with OS as Windows 7. The version of MATLAB is 7.6.0 (R2008a). Thanks

Respuesta aceptada

Matt Fig
Matt Fig el 1 de Dic. de 2012
Editada: Matt Fig el 1 de Dic. de 2012
I would be willing to bet that reason you experience the speed increase is that when you issue the CLEAR command you are not only clearing the variables but also the pre-compiled functions from memory. Have a look at this:
clear all
inmem % Should be very little in memory.
F = repmat(2,3,4);
t = ismember(1:4,5:6);
inmem % M-files are compiled into memory for fast use.
clear all
inmem % The above M-files are gone again....
So if you use a lot of M-files that need to be compiled every time you issue a CLEAR, that will eat up some time. Also, depending on how things are running, you might be over-writing variables when you don't issue CLEAR rather than creating new ones, which also takes time.
As for your code taking 30 minutes, that might be something that could be reduced dramatically but it is hard to tell without seeing the code. It can take some time and experience to learn how to speed up MATLAB code, but it may be worth it. Just recently I helped a guy take his code from a running time of 50 minutes to right around 3 seconds. It is not always possible to do that, but it just depends. Good use of vectorization, proper pre-allocating of memory, smart code order and algorithm use - all of these contribute to the final running time.
  3 comentarios
Jared
Jared el 2 de Dic. de 2012
After a simulation: >> inmem
ans =
'matlabrc'
'pathdef'
'userpath'
'ispc'
'filesep'
'general\private\openm'
'pwd'
'usejava'
'hgrc'
'colordef'
'whitebg'
'isunix'
'jet'
'gcf'
'dot'
'opaque.char'
'initprefs'
'initdesktoputils'
'findallwinclasses'
'path'
'str2double'
'fullfile'
'reporterrorlogs'
'now'
'close'
'edit'
'findall'
'datenum'
'javachk'
'sym.char'
'timefun\private\formatdate'
'timefun\private\dateformverify'
'timefun\private\cnv2icudf'
'datevec'
'cellstr'
'iscellstr'
'sym.diff'
'sym.minus'
'cell.strmatch'
'strmatch'
'mdbstatus'
'workspacefunc'
'num2str'
'repmat'
'fliplr'
'uiopen'
'cell.strcat'
'strcat'
'isdir'
'fileparts'
'open'
'finfo'
'strtok'
'imfinfo'
'imagesci\private\isxwd'
'imagesci\private\istif'
'imagesci\private\isras'
'imagesci\private\isppm'
'imagesci\private\ispnm'
'imagesci\private\ispng'
'imagesci\private\ispgm'
'imagesci\private\ispcx'
'imagesci\private\ispbm'
'imagesci\private\isNonEmptyString'
'imagesci\private\isjpg'
'imagesci\private\isico'
'imagesci\private\ishdf'
'imagesci\private\isgif'
'imagesci\private\isfits'
'imagesci\private\iscur'
'imagesci\private\isbmp'
'imagesci\private\imftype'
'imagesci\private\getFileFromURL'
'imformats'
'ismember'
'Element_Plotting'
'File_Opener_8nodeISO'
'mdbfileonpath'
'blanks'
'TCLAP_8nodeISO'
'funct_element_connectivity_8nodeISO'
'funct_symbolic_stiffness_matrix_8nodeISO'
'funct_b_matrix_integral_8nodeISO'
'funct_symbolic_thermal_load_matrix_8nodeISO'
'funct_C_matrices_8nodeISO'
'funct_jacobian_8nodeISO'
'funct_thermal_strains_8nodeISO'
'funct_global_stiffness_matrix_8nodeISO'
'funct_boundary_conditions_8nodeISO'
'funct_reduced_stiffness_matrix_8nodeISO'
'funct_nodal_force_array_8nodeISO'
'funct_reduced_displacement_array_8nodeISO'
'funct_displacements_8nodeISO'
'funct_displacement_function_8nodeISO'
'funct_strain_8nodeISO'
'funct_stress_8nodeISO'
'funct_forces_8nodeISO'
'linspace'
'syms'
'sym.sym'
'sym.maple'
'maple'
'int2str'
'rat'
'log10'
'sym.mtimes'
'mapleinit'
'sym.plus'
'run'
'k_element_symbolic_2_numeric'
'thermal_strain_symbolic_2_numeric'
'unique'
'B_FEA_symbolic_2_numeric'
'EXCEL_data_write_file'
'figureToolbarCreateFcn'
'graphics\private\clo'
'initprintexporttemplate'
'cell2mat'
'ind2sub'
'lineseries'
'newplot'
'gca'
'cla'
'setdiff'
'title'
'xlabel'
'ylabel'
'axescheck'
'axis'
'objbounds'
'grid'
'gcbf'
'closereq'
'gcbo'
'xlswrite'
'num2cell'
'actxserver'
'winfun\private\newprogid'
*
After a 'clear all':*
>> inmem
ans =
'workspacefunc'
'imformats'
>>
Thanks a lot. Now when I run this program, I'll just load up a saved Workspace (w/ all the function) the run the code.
I'm going to try to refine my code by running a new M-file that clears the plethora of variables only while leaving the functions alone.
Matt Fig
Matt Fig el 2 de Dic. de 2012
The use of the symbolic engine definitely slows things down. Which version are you using?

Iniciar sesión para comentar.

Más respuestas (2)

Jan
Jan el 2 de Dic. de 2012
Editada: Jan el 2 de Dic. de 2012
Are you using clear or clear all? Matt is right, reading the functions again after a clear all consumes time, but not 15 minutes. Such effects appear only, if a called functions calls clear all repeatedly, e.g. 1000th of times.
If you are using scripts, the uncleared variables can mean a pre-allocation also. Letting a variable grow iteratively consumes a lot of resources. You find a lot of examples for the keyword "pre-allocation" in this forum.
  2 comentarios
Jared
Jared el 3 de Dic. de 2012
Hello Jan,
I was using "clear" before using "clear all" in the example Matt gave. I was manually entering "clear" in the command space. There is no function calling "clear" or "clear all" 1000's of times.
If you look at the mem list posted above, all the things that have the prefix "funct_....." are the actual functions that I wrote that are called. Some of these functions are called thousands of times if there are thousands of elements.
I will see where pre-allocation can be used in my code and see if that makes any significant changes in speed. Some of these files I wrote 6 months ago (this program was a continual work of a period of months). So I'm sure I didn't pre-allocate a variable and its size on some of this stuff. Yes you do see pre-allocate a lot. But for most programs it has negligible effect. My case is when it REALLY needs to be used I guess. I'll get back with you on that.
I wish there was a way I can copy and paste my code w/o having to reformat it in the text box. Sigh.... way too many lines.
Jan
Jan el 3 de Dic. de 2012
Add an empty line before and after the code, paste it, select it and hit the "{} Code" button. Then only empty lines inside the code are mal-formed, but there is not method to avoid this currently.
While pre-allocation does not matter, if you join a dozen of values only, the general strategy to pre-allocate in general and without any exceptions does not fail, when a part of the program is called unexpectedly for larger datasets also. Usually a serious analysis of all possible inputs takes longer than to insert the standard pre-allocation code.

Iniciar sesión para comentar.


husain
husain el 9 de Abr. de 2016
dear Matt Fig ,
your really aswesome you had solved my problem also thanking you very much

Categorías

Más información sobre Performance and Memory en Help Center y File Exchange.

Community Treasure Hunt

Find the treasures in MATLAB Central and discover how the community can help you!

Start Hunting!

Translated by