MATLAB: Speed, functions and overheads

functionoverheadspeed

Dear all,

I have noticed using functions, nested functions and sub-functions considerably decrease the speed of execution. Is it possible to decrease the overhead incurred when calling a function?

Thanks, Patrick

Best Answer

x = rand(1000, 1000);
tic;
for k = 1:1e3
  m = mean(x);
end
toc;
tic;
for k = 1:1e3
  m = sum(x, 1) / size(x, 1);
end
toc;

I assume, but cannot test currently, that there is a measurable difference in the timing due to the overhead for calling the M-function mean() (at least until 2009a it was an M-file).

Of course there is no magic flag to reduce the overhead, otherwise TMW would not have disabled this. So inlining the code is the only way to avoid the overhead. The resulting code is faster for the price of a reduced readability.

[EDITED] Summary of my comments:

When you call functions, you cannot avoid the overhead.
When you inline the code instead, the overhead vanishes, but other difficulties arise.
Tertium non datur.

Related Solutions

MATLAB: Is it better to have one function or multiple instances of one code

I never write scripts, because the variables declared in one script interfere with other scripts. Any possibility to influence parts of the code, which are far awy, is a source of bugs - see https://en.wikipedia.org/wiki/Action_at_a_distance_(computer_science).

But the question remains, when to separate a part of a function to create a new function. This can be desided by the code complexity, but it is a question of taste, how you measure it and where the limit is. But as soon as a piece of code is a compact unit, which can be reused from other functions also, it is worth to move it to an own function. Then it be be tested exhaustively by a unit-test. If it is a bottleneck for any code, it can be optimized or mex-ed, and then all codes using this subfunction wil profit from the speed.

There is a certain overhead in calling an M- or built-in function. The latter is faster, e.g. calling mean(X) is slower than sum(X) / numel(X). But this overhead is small.

Sometimes the error checks in functions take more time than the actual computations (see polyfit). But this is a different problem.

While the runtime of inlined code can save milliseconds of runtime compared to functions, the time for programming and debugging can profit massively from this. If you have 4 almost identical parts, it will be a mess to apply a modification of the code compared to having 1 external function with a parameter for the differences. Therefore copy&paste programming is considered as anti-pattern. Maintaining or expanding such code is too prone to typos.

Caring too much about the runtime during the programming is often a premature optimization: The goal is to solve the problem. Then concentrating on the runtime at the beginning can lead to unreadable code which cannot be adjusted or expanded anymore. It is smarter to create a stable and clean code at first and find the bottlenecks for the runtime later. Then you can be sure not to "optimize" any code, which takes 1% of the total runtime only, such that a 100% speedup of this part reduces the total runtime by 0.5% only.

I've seen the advice, that subfunctions must be created, when the main function exceeds 1000 lines of code. Others use the a limit of the "Cyclomatic complexity", e.g. McCabe complexity > 10 to determine the need to move code to subfunctions to allow a complete testing. Another idea is: "If you cannot describe the job of a function in one sentence anymore, split it into subfunctions."

You see: runtime does not appear in the criteria, but the reduction of complexity rules to avoid bugs and improve the maintainability.

MATLAB: Is the built-in dot product function somewhat inefficient

Other than the supposition that dot() needs to be more generic for the multi-dimensional cases it must cover, the "why" is unknown. But this has been observed and reported on this forum and on the newsgroup several times before. The cross() function is another example of a supplied MATLAB function that can easily be beat for speed by simple hand-written m-code in simple cases.

If it is a bottleneck for timing in your application, go ahead and use your own hand-written code. That's what I do. For 1D vectors, simply writing the result as a matrix multiply would be preferred. E.g., an example with very large vectors:

>> format long g
>> v = rand(10000000,1);
>> w = rand(10000000,1);
>> tic;disp(dot(v,w));toc
           2498633.9177071
Elapsed time is 0.060657 seconds.
>> tic;disp(v'*w);toc
          2498633.91770709
Elapsed time is 0.007192 seconds.

In the latter case, the multiply itself is passed off to a very fast highly optimized BLAS library routine in the background.

Best Answer

Related Solutions

MATLAB: Is it better to have one function or multiple instances of one code

MATLAB: Is the built-in dot product function somewhat inefficient

Related Question