Why the computing time of a function is bigger than main fuction?

1 view (last 30 days)
The computational time of first tic-toc is 0.000050 seconds.and second computatioal time is 0.000521 seconds. Nearly ten times bigger. Is there a way to decrease elapsed time for functions?
function main
clear;
clc;
a=1:10000;
tic
for i=1:10000
a(i)=a(i)+1;
end
toc
b=1:10000;
tic
b=myfunction(b);
toc
end
function b=myfunction(b)
for i=1:10000
b(i)=b(i)+1;
end
end

Answers (4)

Titus Edelhofer
Titus Edelhofer on 29 Mar 2012
Hi Volker,
hmm, it's not a deep copy that happens here. To see, that the operation indeed is done inplace can be seen when using the taskmanager. Run the following code and take a look at memory consumption (note, adapt the size of n to something that does not blow your memory).
function main2
n = 10000; % this makes a and b a 750 MByte matrix!
a=rand(n);
tic
for i=1:numel(a)
a(i)=a(i)+1;
end
toc
disp('now b is created <return>')
pause;
b=rand(n);
disp('Now call myfunction <return>')
pause;
b=myfunction(b);
end
function b=myfunction(b)
tic;
for i=1:numel(b)
b(i)=b(i)+1;
end
toc
end
I see a jump in memory of about 750MB for running until the first pause, and then a jump of the same size when creating b. But no jump when calling myfunction, so b is not copied when going to myfunction.
Why the loop in myfunction is still by a factor of three slower I have no clue and will ask our development.
Titus
Edited: use n instead of hard coded 10000 I had before.
  6 Comments
Jan
Jan on 29 Mar 2012
Although the JIT can accelerate loops dramatically since Matlab 6.5, I hear the old rumor "FOR loops are brute slow in Matlab" too often. The positive effects of the JIT can be observed, when the debugger is enabled by setting breakpoints, or when the profiler is active: Both would collide with the reordering of the commands, such that the JIT is disabled. Especially for the profiling this is critical, because it reduces the meaning of the results substantially. Suddenly fast loops look like a bottleneck!
I still do not understand, why the dynamic evolving of the JIT is an argument not to publish a documentation. This is funny. Imagine: "Yes, Windows 7 has a lot of new powerful features, but we do not tell you how to use them, because these feature could be change in Windows 8".
I do not think that too many average users will be too clever and create inefficient programs by considering a specific JIT feature only. Only the advanced users will adjust their programs to the JIT, but currently they can't. If a customer asks me, if he can process some data with a program in realtime using WinXY/Linux/MacOS and Matlab20XY.i/abBit, I have no chance but trying it, if the speed depends on the JIT.
I have to write code working with Matlab 6.5 to 2011a. Because a lot of features have changed in this time, I need to branch depending on the Matlab version very often. It would not be a drawback, if I write a general implementation without JIT adjustments, and a specific version adjusted to the JIT of Matlab2009a/32. This will give the full speed on this specific version only - but it does at least. And this can be the dominant argument to use Matlab to solve this specific task.
My opinion: JIT-documentation (even with volatile character) => more power for power-users => more sold Matlab licenses.
Matlab is stable, powerful and user-friendly. The main drawbacks are the slow speed and the weak GUI capabilities. Both of them can be mitigated using undocumented features. So why not document them?!
Titus Edelhofer
Titus Edelhofer on 30 Mar 2012
Hi Jan,
thanks for the detailed discussion. Yes, turning on the profiler already changes the way things are handled. I admit I've been once mislead as well when the profile told me, I was doing a better job then before, but with turned off profiler the contrary was the case. Usually though he fortunately points me to the bottlenecks where to search for inefficiencies.
Regarding the documentation about what JIT does and what not: I don't know about reasons why not to give more detailed explanations about how it works, what it does etc., sorry ...
Titus

Sign in to comment.


Jan
Jan on 29 Mar 2012
The additional time for calling the function is only partially an overhead of the function call. Mainly it is the effect of the required deep data copy of the vector. At first only a reference to the vector b is submitted to the function. But in the first iteration b is duplicated, and this needs time. In opposite to b, the vector a is not duplicated.
You can test the effects by:
function main
a=1:10000;
tic
for i=1:10000
a(i)=a(i)+1;
end
toc
b=1:10000;
b=myfunction(b);
end
function b=myfunction(b)
tic;
for i=1:10000
b(i)=b(i)+1;
end
toc
end
Now I get:
Elapsed time is 0.000103 seconds.
Elapsed time is 0.000836 seconds.
To answer your question: No, there is no way to accelerate subfunctions. To gain speed it is useful to avoid deep data copies by processing the variables locally.
  1 Comment
Volkan Kandemir
Volkan Kandemir on 29 Mar 2012
Thank you Mr Jan. If the main reason of time differences is calling subfunctions, it is good for us, since it will not increase with the size of the data. However, as you mentioned duplicating big datas is very time consuming.
What you mean by "processing the variables locally." Do you mean don't use subfunctions or there is a way to use subfunctions with out duplicating datas like pointers?

Sign in to comment.


Titus Edelhofer
Titus Edelhofer on 29 Mar 2012
Hi Volker,
which version of MATLAB are you using? For me (R2012a) both your and Jan's version give more or less the same results. With your code the second tic/toc is about 20% slower (only). In "older" versions (if I remember somewhere before R2009a) the function is indeed slower (see Jan's explanation), whereas in newer versions there should be no deep copy involved, the operation on b should happen "inplace" ...
Titus
  2 Comments
Volkan Kandemir
Volkan Kandemir on 29 Mar 2012
I am using R2012a too.
How is the second tic/toc slower 20% only? First one is 0.000103 seconds where as second one is 0.000836 seconds on Mr Jans's computer. The ratio is (0.000836-0.000103)/0.000103*100=711% slower!!
Yes I am using inplace functions also global variable but those are not helpfull.
Titus Edelhofer
Titus Edelhofer on 29 Mar 2012
Sorry, I must have made a mistake when running the code (perhaps missed a digit). Now I get the same "bad" ratio as you and Jan ...

Sign in to comment.


Jan
Jan on 29 Mar 2012
function [a, b, c] = main
n = 1e6;
a = 1:n;
tic
for i = 1:n
a(i) = a(i) + 1;
end
toc
b = subfunc1(n);
c = subfunc2(n);
end
%
function b = subfunc1(n)
b = 1:n; % Size of [b] depends on input
tic
for i = 1:n
b(i) = b(i) + 1;
end
toc
end
%
function b = subfunc2(n)
n = 1e6; % Overwrite input, fixed size of [b]
b = 1:n;
tic
for i = 1:n
b(i) = b(i) + 1;
end
toc
end
Results:
Elapsed time is 0.011078 seconds. main
Elapsed time is 0.021114 seconds. subfunc1
Elapsed time is 0.010048 seconds. subfunc2
Interpretation: subfunc1 is much slower, because the size of n is not fixed. Obviously the JIT can profit from fixed size loops.

Tags

Community Treasure Hunt

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

Start Hunting!