How to check in which step MATALB code is running?

I have made a code which took approx 4-5 hours to execute.....So how could I know on which step that code is running and how much time will it take to complete ?

[Hyderkkk]

ctrl+c in commend window

[Walter Roberson]

control-c will abort the execution!

Answer 1

[Star Strider]

Without seeing the code it’s impossible to say exactly. However when I run long simulations (usually with at least one loop), I start a time counter with the clock function at the beginning of the program (before the start of the loop), and just prior to the ends of the main loop, I put an fprintf statement that reports what the loop counter is, uses the etime function to show how long that loop took, and another calculation of how long the entire program has been running. All that prints in the Command Window. One fprintf statement like that doesn’t slow the code down noticeably, but it can be reassuring.

Answer 2

[Ben11]

You might also want to look into dbstack, which tells you the actual line of code being executed.

Answer 3

[Walter Roberson]

At some point after 2014, if you happened to have an editor window open to something executed by the code, it became possible to set a breakpoint even though the code was already running.

If I recall correctly, while you are running you cannot use the editor ribbon to browse files to bring up your code if it was not already open (though I think it is sometimes possible if the file is on the Recent list.)

Answer 4

[John D'Errico]

I tend to use things like waitbars, or some informative output that gives me a clue. For example, I have been recently running a massive set of computations recently, but there are intermediate points where I can efficiently update a waitbar. And while waitbars themselves can be costly, IF you update them thousands or millions of times, in my case, the waitbar is typically updated only a few dozen, or at most a few hundred times. And even better, I can even predict the amount of time that will be needed to complete the result. The process tends to be weakly quadratic in nature, so I can have good estimates of the predicted time. This allows me to know if I should wait up, or just go to bed and expect a result the next morning.

The point being, use waitbars in creative ways. Or display a limited set of intermediate results when possible. This helps to convince you that the code is working as designed, and not stuck in an infinite loop.

[Walter Roberson]

https://www.mathworks.com/matlabcentral/fileexchange/22161-waitbar-with-time-estimation even does time estimates