adding breakpoint to program slows it down a factor of 250x

I observed this in a larger program, then created a simple test case to ask this question.

The following program takes 0.038 seconds to execute without any breakpoints.

    tic;
    for  ii=1:16000000
        xyz=1; 
    end
    toc;  
    z=1;

But if I set a breakpoint at the line of code for z=1, it takes 9.3 seconds to execute.

Is this normal? Is my system corrupted somehow? Any feedback much appreciated.

Rebooting the computer doesn't make a difference. I have 32G of RAM available so that shouldn't be the problem. Not sure what other knobs are available to try to get better performance.

Answer 1

[Matt Fig]

It makes sense to me that MATLAB would be slower when you are debugging. So what is the big deal? You won't be in debug mode once the program is ready for use, will you?

[gkk gkk]

If I set a breakpoint in the middle of my larger program it takes an hour to reach it... not very useful for developing. I suspect something isn't quite right here. Slower sure, but not THAT much slower. There must be something wrong somewhere. What about if you run the sample program above on your system, do you see the same performance or is it much faster with the breakpoint set?

[Matt Fig]

Ah yes, you didn't mention that in the original post! Have you tried to use:

dbstop if error

instead of setting break points? That is faster.

[gkk gkk]

Actually, stop on warning produces same results (> 9 seconds). But, stop on error as you say is fast (0.04 seconds, same as with no breakpoint). Is that what you'd expect?

[Matt Fig]

Based on experience, yes. I don't know why, but this is what I have found in the past. If I want to force a break at a point and it is taking too long I can call

dbstop if error

then make the code stop where I want by calling

error('Here I am on line 366')

[gkk gkk]

True, but then you can't continue the program. Is that right? At least I haven't figured out how.

[Matt Fig]

To continue use TRY-ERROR-CATCH and

dbstop if caught error

then DBSTEP, DBCONT, etc work.

[gkk gkk]

Thanks, any chance you can run the for loop above and report timing with and without a breakpoint? It'll help me understand whether there's anything unusual going on in my system.

[Matt Fig]

I did. Without, .037 seconds. With a break point on the last line, 4.43 seconds. Like this:

function [r] = check_debug()
% Run in normal and with breakpoint on r=1.  Observe time difference.    
tic;
for  ii=1:16000000
    xyz=1;
end
toc;

try
    error('Here I am on line 10')
catch
end

r=1;

I run from the command line and get the following output. As you can see, the code is fast this way and I can still step through.

>> dbstop if caught error
>> check_debug
Elapsed time is 0.037994 seconds.

Caught-error breakpoint was hit in check_debug at line 10. The error was:

Error using check_debug (line 10)
Here I am on line 10

10      error('Here I am on line 10')
K>> whos
  Name      Size            Bytes  Class     Attributes

    ii        1x1                 8  double              
    xyz       1x1                 8  double              

K>> dbstep
14  r=1;
K>> dbstep
End of function check_debug.
K>> dbcont

ans =

       1

[gkk gkk]

Thanks so much Matt, that really helps.

Answer 2

[Teja Muppirala]

Might I suggest using the KEYBOARD command? It's a bit simpler than setting up dbstops and trys and catches, and works just as fast.

    tic;
    for  ii=1:16000000
        xyz=1; 
    end
    toc;  
    keyboard;
    z=1;

[Matt Fig]

Indeed!

[gkk gkk]

Great! And there's no hit from performance using keyboard.