Notice the part talking about global variables, "This is because to look for global variables, MATLAB has to expand its search space to the outside of the current workspace." . When you use a script, every name you give has to be searched for in the workspace of the caller, or in the base workspace if there is no ultimate calling function. Using a function permits narrowing of focus.
This does not mean that every variable reference inside a script is certain to be slower than the slowest (non-global) variable reference inside a function: this is an "all else being equal" situation. If you had a clear base workspace and only one variable, then there isn't far to search, so potentially a script run in a near-empty base workspace could end up with faster variable references than a function that had a lot of variables.
Notice also the part about global variables, "Furthermore, the reason a function call involving global variables appears a lot slower than the others is that MATLAB Accelerator does not optimize such a function call." This is because any called function might have a "global" that changes the value of the variables, so if you had, for example,
result = mySine(B) .* mySine(B)
then if B was global MATLAB would have to assume that it might change in between the two references, and so cannot short-cut this to
internal_temp = mySine(B);
result = internal_temp .* internal_temp
When you are using scripts, then there is a similar problem: any routine can assignin('base'), so MATLAB cannot assume that variable B in the base workspace would not be changed by mySine().
Or consider the meaning of
T = 0;
for K = 1 : 10
myScript;
T = T(1) + zeros(1,1);
end
What is the end result in T? 0, right, since you are adding 0 ten times and that gives a total of 0, right? No! myScript might have an assignment to a variable named 'zeros', or to 'T', so when MATLAB knows that myScript is a script, it has to disable any optimization of this code and has to look-up where T and zeros are every iteration. And not just where they are but also what they are: the script might have assigned a function handle to T, so T(1) might be a function call. Thus, it is not just the execution time of the script itself: it is also the execution time of anything that refers to the script.
Also, each time a function is first encountered, it is parsed, and the parsed version is cached. A script is potentially only parsed line-by-line, or potentially only syntax checked once each time it is encountered before it starts executing (so, for example, if you are missing an "end" statement then it might notice that before beginning execution.) No Just-In-Time compilation is promised for scripts.
That said: later versions of MATLAB have become better and better at doing Just In Time compilation on scripts. Part of the way that has been accomplished is that Mathworks has been redefining the meaning of what scripts do. In new versions of MATLAB, the loop I gave above was redefined to continue to refer to the function zeros() even if zeros is redefined in the script. To get the old behavior you would have to assign something to zeros before the call, such as
zeros = [];
T = 0;
for K = 1 : 10
myScript;
T = T(1) + zeros(1,1);
end
You could assign anything: MATLAB just needs to see the signal that the name is to be a variable (including possibly a function handle) rather than a reference to an outside function.
Best Answer