Matlab R2016 runs much slower calls to .m files than R2013

I am completely new to Matlab R2016b (previous version R2013a) and the same code runs around 10 times slower (profile checked) in the new version. The code has several calls to .m files (not functions, just scripts) and all signs that calls are the problem. If I run the complete code, without calls, there are minimal differences between them; although surprisingly 2016 is still slower (1.5 times)...frustrating.

Maybe several calls to a .m file is not the most efficient manner, but it allows me to keep the code and different versions organized...anyway, why Matlab2016b is slower?

Thanks in advance!

[Steven Lord]

Please post a SMALL segment of code with which you can reproduce this behavior and/or send the code to Technical Support for investigation.

[Javier]

I have wrote a simple code in order to show it. First, I Run And Time the program General.m:

H=30;
a=rand(H*86400,1);
d=zeros(H*86400,1);
for i=1:size(a,1)-H
b=max(a(i:i+H));
c=min(a(i:i+H));
d(i)=b*c;
end

Total time in Matlab R2013a: 14s. Total time in Matlab R2016b: 5.4s Congrats Matlab 2016!

However, if I split the original code in two parts General_v2.m:

H=30;
a=rand(H*86400,1);
d=zeros(H*86400,1);
for i=1:size(a,1)-H
sub_max
d(i)=b*c;
end

where sub_max.m is

b=max(a(i:i+H));
c=min(a(i:i+H));

the results are:

Total time in Matlab R2013a: 46s. Total time in Matlab R2016b: 108s!!!

2013 version runs the same code 3 times slower, but 2016 20 times slower!

I really do not understand at all! Thanks again!

Answer 1

[Javier]

It seems that new Matlab version R2017a has solved this problem, see Performance section: "MATLAB has improved the performance of invoking scripts, especially when invoking a script from another script.".

I have just installed it and tested the code and now the speed between 2013 and 2016 is very similar. I just want to put this on the record in case someone has the same problem.

Thank you all guys for your time.

[Jan]

I've accepted this answer, because it solves the problem. Thanks Javier for this detailed problem description.

Answer 2

[Philip Borghesani]

This answer is a bit late but the problem here is breaking code up into scripts instead of functions. Using R2016b you can create local functions inside of scripts and will find that this code runs nearly as fast as the original:

• mycode.m:

tic
H=30;
a=rand(H*86400,1);
d=zeros(H*86400,1);
for i=1:size(a,1)-H
d(i)=sub(a,i,H);
end
toc
function prod=sub(a,i,H)
  b=max(a(i:i+H));
  c=min(a(i:i+H));
  prod=b*c;
end

In any matlab version you can use the same code but place sub in a separate file. In the long run your code will be much more maintainable and run faster if you learn to work with functions.

[Javier]

Thank you Philip for your answer. Some days ago I wrote to Matlab Technical Support and this was their answer:

"The issue you are experiencing is a know limitation that the developers are currently aware of. Essentially, when a script or function is called inside a loop, a significant time is spent in dispatching the script, because of a high overhead in the dispatching algorithm in R2016. The development team will make a decision regarding the MATLAB release in which this issue will be addressed, however, at the moment, there are no known workarounds rather than replacing the call to the script/function by its body. I apologise for this inconvenience."

So bad news, this is a known problem and maybe would not be addressed. The use of functions, as you suggested me, I think is not a viable solution, due to I have around different 30 input parameters on each function, so handle that sentences and modify all of them every time I do a change can be very tedious. In fact this is the reason why I change to scripts.

Thanks anyway, any suggestion is welcomed!!

[Jan]

According to the answer of TMW, the problem concerns scripts and functions. But functions have further advantages. Especially "30 parameters" sounds like a complicated transfer of variables. Then combining them in a struct with increase the readability.

[Steven Lord]

I agree with Jan on the subject of packing your parameters into a struct (or perhaps an object.)

With thirty separate input arguments, remembering the order in which the functions accept a particular input must be challenging. For example, people on Answers and CSSM have had more than enough trouble in the past with missing one of the ten inputs fmincon accepts in its "biggest" syntax! In addition, some functions that only directly need one of the parameters may need to accept many or all of them, simply to support functions they call or to have a consistent signature.

Packing everything into a struct means that functions that use one of the parameters have access to all of them, but can ignore any that are unnecessary or inapplicable to that function. It also lends itself to expansion. Rather than needing to modify function signatures to add a thirty-first parameter, you simply need to add parameter 31 to the struct and use it in the functions that need it. Those that don't use it don't need to know or care that it exists.

[Javier]

Thanks to all of you for your suggestions. During last days I have tried a solution that involves v2struct every time I call a function (pack/unpack), something like this:

S = v2struct;
S=my_function(S);
v2struct(S);

where myfunction.m is:

function S=myfunction(S)
v2struct(S);
main code
S = v2struct;

Of course this solution is much worse than the original code, calling .m files in R2016. I have to repeat this way of calling functions around 365*17280 times, so Matlab spends all the time in the v2struct function. Is there any way of doing this in a more efficient way?

I suppose that a suggestion could be to change the whole code and rename all the variable as a structure, just adding before the variable name S.variable_name . However, I have around 190 variables spread in 25 scripts (now functions) with (you can imagine) several lines of code, so therefore, and without a doubt, I would return to Matlab 2013.

[Philip Borghesani]

I for one would not want to be maintaining your code base. Rework (refactor) your code one step at at time. Structs are not the whole answer but may be part of the solution.

1. Start on the inside: find a block of code that has a minimal set of dependencies and preferably contains at least the inner for loop and turn that into a function.
2. If there are multiple blocks of code that use the same super set of parameters then place those in a strut but never do the pack/unpack thing, use find and replace to update all uses. You will find that even in R2013 your code will run faster and be easier to maintain.
3. As a stopgap measure you might try using some globals. I would not normally recommend this but in your case globals are better then one colossal workspace and all scripts.
4. At some point your code will be ready for the latest version of matlab and you will want to use some new feature.