Simple Code taking too much time

the code below is part of a large program and is looped through about 50 times total. I haven't worked on this code in a while but it was running fine. I made some very slight changes to other parts of the program and now it is taking too much time to run (it used to take around 2 hours for the 50 loops, now I leave it for around 16 hours and its is still in the 40t loop). below is the part of the code which is taking more than 99% of the run time. I used profiler and the line between asteriks is the one taking a very long time to run although it is a simple addition. this starts happening after the 20th loop roughly (even if I start at the 20th loop, I still have the issue).

while (x<=ceil(((xT+8*tXD)-X1)/dX))
       y=max(floor(((yT-8*tXD)-Y1)/dY),1);
         while (y<=ceil(((yT+8*tXD)-Y1)/dY))
           Tdist=(x*dX+X1-xT)^2+(y*dY+Y1-yT)^2;
            if (abs(sqrt(Tdist)/tXD) < 8)
              dSi=((tFv*tdV)*1+ZZ(i,j)*cov))/(2*pi*tXD)*exp(-0.5*TdisttXD);
             *** dS(x,y)=dS(x,y)+dSi;***
            end
           y=y+1;
         end
       x=x+1;
   end

Any ideas as to what could be causing such delay in such a simple step. dS is already preallocated. I'm not an expert in MATLAB but id doesn't make sense for a simple addition step to take so long while more complicated steps are executed quicker.

[Jonathan Sullivan]

You're right. That doesn't make sense. Did you modify the code while it was running? That can cause the times to be displayed next to the incorrect lines.

Also, what is the size of dS? How frequently does the if statement return true?

[per isakson]

Can you turn this code into an executable example with the help of a few rand

BTW: There is a problem with the parentheses in

    dSi=( (tFv*tdV)*1+ZZ(i,j)*cov ) ) / (2*pi*tXD)*exp(-0.5*TdisttXD);

[Mohammad Kabalan]

Jonathan, I did not modify the code while running, and I ran many trials since I started having this issue. the if statement returns true around 60% of the times, dS is 2501x2501.

Per, the problem with the parentheses happened when copying the code (there's a "(" before the 1+ZZ... in the actual code).

It's hard to make a running example, the program is very large and this is only a very small part of it.

[per isakson]

Is it possible that memory usage is part of the problem? See: Profiling Matlab memory usage

Did you observe the memory usage in the Windows Task Manager while running your program?

[Marc]

It is almost impossible to help you here without knowing what is going on outside of this loop. Can you put some counts in there to see how many times each while and if statements are being evaluated? I agree that looking at the code, it does not seem like it should be a time hog but it is hard to know what ceil and floor are doing with your conditional statements.

[Marc]

Just one last random thought.... Is this some kind of finite difference scheme? Turning some PDEs into odes and using ode15s or something?

I ask because I ran profiler on something like that, where the function is 3000+ lines, using nested functions to get around global variables and it ran like 10X longer than tic/toc and internal clock calls with etime().

I never followed up on the profiler hiccup but you may want to add some calls to clock with etime and see if this compares well to the profiler.

[Mahdi]

Maybe the problem is that, that line is being called so much (which seems inevitable), because as you said it is just a simple addition.

Answer 1

[Guru]

This simply looks to be a case where you are trying to make some result converge to an answer, and the system is not set up to converge nicely with the given settings.

The issue that you have is not a result of the code that is asterisked takes very long to run, it's that you have a nested while loop where the adjustments you are making simply do not converge to anything. MATLAB however will still try to optimize it, and to handle this problem you should use the optimization functions within the Optimization toolbox rather than try to use your own optimization routines unless you build in some kind of metric that detects there is no solution that it can converge to.