- Avoid clearing more code than necessary. Do not use clear all programmatically. For more information, see clear.
- Avoid programmatic use of cd, addpath, and rmpath, when possible. Changing the MATLAB path during run time results in code recompilation.
- Avoid functions such as eval, evalc, evalin, and feval(fname). Use the function handle input to feval whenever possible. Indirectly evaluating a MATLAB expression from text is computationally expensive.
- Avoid functions that query the state of MATLAB such as inputname, which, whos, exist(var), and dbstack. Run-time introspection is computationally expensive.
How bad is the performance of run time introspection?
2 views (last 30 days)
Naor Movshovitz on 18 Jan 2017
From the doc (Techniques for improving performance):
Avoid functions that query the state of MATLAB such as inputname, which, whos, exist(var), and dbstack. Run-time introspection is computationally expensive.
Fair enough. But are these functions to be avoided in loops and frequently called lines or can they also cause degradation of performance in other ways (e.g. disrupting JIT etc.)? It's hard to test these ideas even with the aid of the profiler, without completely removing every trace of the suspect functions from the code. But if no one knows the answer I will make the experiment and report back.
Philip Borghesani on 18 May 2017
Since R2015b functions that introspect are just slower, they do not generally disrupt any other optimizations. I would probably order the list in that doc note differently in terms of importance:
One of the reasons eval functions are slow is that they must due the same introspection done in the last group of functions.
The more times a function is run the more MATLAB tries to optimize it. Clearing the function (possibly due to CD or path manipulation) starts the optimization process back at the beginning, that is the only disrupting influence I can think of.