Why is script execution way faster in 2015b than in next versions when computed several times ?

Hi everyone,

I have an issue with a complex code that works only in R2015b (or previous versions I suppose). The code calls a complex script multiple times (thousands of times usually). In 2015b, when it is called a first time, it take approximatively 110sec and after, the time is really decreased and is less than 0.1sec.

However the same code in versions R2017, 2018 and 2019a the first time the script is called it is faster but after not only it doesn't get much faster over the next steps but it shows a memory error: " Out of memory. Type "help memory" for your options. "

The script is obtained from functions and syms operations, that's why it looks a bit messy. (It cannot be well implemented as a function, even though I tried and I had the same issue)

So my questions in the end would be:

Why are the next versions of Matlab not running the scripts the same way as previously ? (as if the script is stored and known in R2015b but not in the next versions ).

Is there a way to have the same execution process as in 2015b but with the matlab elements added of next versions (pause etc..)

Why is there a memory error appearing in R2017a to R2019a versions when the exact same code/variables and data are in the previous 2015b?

Thank you in advance for your help and answers, please don't hesitate to ask any questions if you're not sure about what I tried to explain.

(Please find the script in question attached, a similar one is experiencing the same issue ).

[darova]

Too many trigonmetric operations i think

[John D'Errico]

"(It cannot be well implemented as a function, even though I tried and I had the same issue)"

No. YOU could not do it well.

11 lines of code, but each is HUGE.

Sometimes things change from one release to another. Subtle changes in how MATLAB may work with huge lines of code might cause a problem. But more important is in what you may be doing.

I once had a colleague who ALWAYS seemed to create big messes of code like this. In fact, he was proud of his creations, because they looked impressive. He impressed even himself, and was always making sure you knew how good his work was, because of the complexity. In fact however, he also always had problems with that code. Too large to compute with. The code itself was always fraught with numerical problems, because just because a symbolic computation is mathematically correct, it need not be computable in double precision arithmetic. And it was always practically impossible to check any of it. Were there numerical problems? How could he know? Nor could he care, since it looked good.

Hey, all of that could be excused, if he got good results. But in fact, he never seemed to get useful, good results. And everything he ever wrote took as much computer time as the client would afford on the largest computers available.

The proint is, there are always many ways to solve a problem. You can look for the complex solution. Just throw the biggest computer you have at it, and hope the answer you get is valid.

Or, you can use the philosophy my advisor in grad school used. His goal was always to prune down any mathematical model of a system, throwing away the terms that he knew were not necessary to model the physical system at hand, doing that in advance. And this fellow always got useful, meaningful results. His results predicted the behavior of the system under study, and they did that well. They provided useful understanding of the problem, because you could look at what he did, and understand just what was happening.

Now, could I ever convince my colleague who loved the complexities of things, to look for a simpler solution? Of course not. And I probably won't convince you either. Certainly not here, because that would force you to completely rethink your approach. And people don't change. So, good luck. Expect things to get only worse, but the good news is, there is always a bigger computer around the corner.

[darova]

John D'Errico, i like that story.

Can you add it to answer section so i could like it?

[Tristan Barjavel]

Hi everyone,

Thank you for your answers, I totally agree darova and John D'Errico (and by the way, I like really simple codes and I already reduced it a lot compared to the overall complexity of it, that was clearly the first thing I wanted to do).

However, your comments, even if they were good and relevant, did not answers my questions, the thing is not about the script itself, since my overall code for each step takes less than 0.01 seconds in late timesteps for the R2015b version.

Another way to formulate my question would be:

How can I get the same efficiency in execution time as in 2015b in the next releases, 2019a for instance?

Thank you in advance

[Tristan Barjavel]

Hi everyone a small up for this issue...

Let me just add that my problem is not about the script itself, since my overall code for each step takes less than 0.01 seconds in late timesteps for the R2015b version. It is just that it is not working after 2017a releases.

Another way to formulate my question would be:

How can I get the same efficiency in execution time as in 2015b in the next releases, 2019a for instance?

Thank you in advance

[G A]

I suspect that you may have problem with implicit expansion.

https://blogs.mathworks.com/loren/2016/11/10/more_thoughts_about_implicit_expansion/

[Tristan Barjavel]

Thank you for your answer, it seems indeed to ne a possible reason, I will check in more details within the code and Verify If there is not such an issue. Thank you G.A !