What should take the longest time to run in matlab?

I have an argument with my professor at school and even tho I present facts showing that I should be right he does not acknowledge this, could someone help me out or even better, tell me if I am wrong?

Basically I have a code which performs a few operations for example:

tic

x = 1;

y = x + 1;

z = y + 2;

toc

What I have done is put the second and third of these into separate function files, ie:

function y = func_1(x)

     y = x + 1;

end

function z = func_2(y)

     z = y + 2;

end

tic

x = 1;

y = func_1(x)

z = func_2(y)

toc

My professor says they should both take the same time, that using the functions should have no impact on the time it takes to run the whole program. But when I try this running the program with functions take way longer. Who is correct or am I doing something wrong?

Thank you!

Answer 1

[Walter Roberson]

In Matlab, to make a fair comparison, you should put the main routines into files as functions (not as scripts), and you should run several times, taking the minimum of the several runs as the closest approximation to the actual time. You have to use functions and not scripts because functions are more heavily optimized (at least until 2010b); you have to do several runs because the first time through, matlab does internal parsing and leaves the results in memory, available for the second and subsequent runs.

It would be expected that in Matlab, the overhead of calling a function could be significant compared to executing so little in the function. Matlab is an interpreter, not a compiler, so each new function or script that is called has some overhead in setting up debugging and trace-back information, and overhead in creating the "workspace" for the function.

Traditional compilers such as C compilers do not explicitly set up debugging information at run-time: instead, at the time of interruption, the debugger looks up the current instruction pointer in a table to figure out where it is. Traditional compilers such as C compilers do usually have to do some work setting up the stack, but not usually as much as Matlab does.

For some common kinds of programs, it is theoretically possible in a language such as C to pre-allocate many of the local variables for all of the routines, turning stack-relative local references into fixed addresses. Programs that can be compiled that way can have as little overhead for a subroutine call as storing the return address and performing a branch operation; on some processors, the return address gets stored in a very fast register while it is setting up the branch, making the call very fast. Matlab cannot reach that level of optimization. This level of optimization is not usually used in programs, but might be used for very very heavily optimized programs in non-interpreted languages.

One must keep in mind the difference between a low overhead calling procedure that could theoretically be used in a subset of programs, versus generalized calling procedures that do get used in practice. Procedure calls might not add much overhead in theory to straightforward programs in compiled languages, but Matlab is not one of those straightforward programs and it is not compiled.

Answer 2

[Sean de Wolski]

You're correct!

There is overhead in calling a function. There is additional overhead if the function is new or if the command

clear all

has been issued since the last run.

Answer 3

[James Tursa]

For your specific example the functions will take slightly longer. The functions need to be read in and parsed for one thing, and that will probably dominate the above example. But let's put that aside for the moment and not take this into account for the timing. When you call a function in MATLAB, it usually makes temporary shared data copies of the inputs (for scalars it sometimes makes just a deep copy). So that takes extra time. The actual computation is the same for both, and the assignments to y and z will take the same amount of time. But in the function case there will be extra temporary shared data copies of the inputs (or temporary deep copies) that will need to be cleared, so that takes additional time also. But I would guess that the extra time for the function calls will still be pretty fast and the extra time spent doing it will probably be moot in most practical cases that are not this simple.

Answer 4

[Tobias]

Thank you for your answers! As you say, this would not be a problem for a simple task like this, but I have to run a program with a loop for 100s with a time step of 0.00001s.

Ahh well, I guess we have to find a way to work around this! Once again, thank you!

Answer 5

[Matt Tearle]

Just to mess with you, there are some other subtleties about the way MATLAB handles passing data to functions, which will come into play if x is a large array, rather than a scalar. As James mentions, MATLAB passes by value, which means you have temporary copies made... unless you don't actually modify the input, in which case MATLAB doesn't actually make a copy (essentially doing a pass-by-reference behind the scenes). You will, however, get a temporary variable for the output... unless you can take advantage of in-place optimization! Confused yet? Wait 'til I get started!

Really, the best way to settle it is to tic/toc an example. (A realistic example, that looks like your actual function but maybe called a few times, rather than 100s.)

[James Tursa]

Here is the situation as I understand it from a technical perspective (mxArray address means the structure address of the variable itself that you would see by doing format debug):

MATLAB typically passes everything to m-file functions by shared data copy (I am purposely avoiding the term "by value" which is misleading). That means a new variable is created with a different mxArray structure that has the same data pointers (pr, pi, ir, jc) as the original ... i.e. it is sharing data with the original ... and the mxArray structure address to *that* is what is physically passed on to the m-file function. The only exception to this that I am aware of is that for certain calling conditions within functions a scalar is sometimes passed as a deep data copy (i.e., a brand new variable completely that is *not* sharing data with the original). Maybe there are other exceptions as well (anyone know of any?). In general MATLAB does not know at the time of the call whether or not the variable being passed will be modified or not inside an m-file, so it always passes a shared data copy. It doesn't sometimes pass by value and sometimes pass by reference.

If, within the m-file function, an argument variable is modified, then the regular rules apply (as long as it is not a classdef object derived from handle). So if an element of the argument variable is modified then the argument variable is first unshared (if necessary) and then the element modification takes place. Or if the argument variable is set equal to something completely new then the argument variable is cleared and then the new assignment takes place. Etc, etc. If the argument variable is not passed back through the output list then upon return of the function the argument variable is cleared (as are all other non-argument function workspace variables except perhaps parsed constants which might hang around until the function is cleared).

Two important exceptions to the above:

1) If the argument variable is a classdef object derived from handle, a shared data copy is still passed in to the m-file but if this shared data copy is modified inside the m-file it is *not* unshared first, so any changes will affect the original variable also. This behavior is no different than modifications that take place outside the m-file.

2) Variables passed to mex routines are passed by reference, meaning that the actual mxArray structure address is passed to the mex function, *not* the mxArray address of a shared data copy of the original variable as is the case with m-files.

I haven't actually checked the semantics for p-code, but I would presume they are the same for m-files.

[James Tursa]

I neglected to mention that in some cases MATLAB will do operations on the argument variable in-place without unsharing the data pointers first (see Loren's Blog for more info on this), but even in this case it is a shared data copy that initially gets passed to the m-file.