12

Why does adding a method level breakpoint have such a negative impact on program performance in debug mode?

Take the following (somewhat contrived) example:

public static void main(String[] args) {
    long start = System.currentTimeMillis();
    for(int a = 0; a <Integer.MAX_VALUE; a++) {
        long v = a * a;
        if(v == 100) {
            doSomething();
        }
    }
    System.out.println("Time: " + (System.currentTimeMillis() - start) + " ms");
}

private static void doSomething() {          //*** BREAKPOINT 2
    System.out.println("done something");    //*** BREAKPOINT 1
}

The performance of this is approximately:

  • Not in debug: 4.5 seconds
  • Debug, breakpoint 1: 6.0 seconds
  • Debug, breakpoint 2: 47.0 seconds

What's going on? What benefit does the method level debug give us that normal ones can't?

Thanks!

EDIT

The timings are only approximations and include the time it takes me to react to the breakpoint and continue the application (which looks to be roughly about 1 second).

I appreciate that System.currentTimeMillis() is not 100% accurate, however the results are consistent over multiple tests and the difference in performance is massive! In fact, adding the method level breakpoint results in a warning from IntelliJ that it will have an impact on performance.

StuPointerException
  • 7,117
  • 5
  • 29
  • 54
  • Wait, you are measuring performance with breakpoints active? In this case I suppose the performance of your application depends on your reaction speed to advance the debugger, unless I'm not understanding your question. – tom May 14 '14 at 11:23
  • That's true and explains the 1.5 seconds between not debugging and debugging with a normal breakpoint. The 40 second jump is what I'm curious about though - I'll edit the question to make it clear! – StuPointerException May 14 '14 at 11:26
  • Is this consistent over multiple tests? Could it not be that your IDE was slower to react when going to the Debug perspective, Open the debugged class, highlight the line, show the stack, ... – tom May 14 '14 at 11:34
  • I don't believe `currentTimeMillis` is accurate.. https://stackoverflow.com/a/1776053/2591612 – Engineer2021 May 14 '14 at 11:44
  • 1
    @staticx it may fluctuate, but certainly not to the order of seconds. As you can see the OP measures time at start and end only, so there is no accumulation of error. – Ordous May 14 '14 at 11:48
  • @Ordous: That is incorrect. Read up on the differences. – Engineer2021 May 14 '14 at 11:48
  • 1
    @staticx I am quite aware of timekeeping and how it can influence things. Should this have been a proper experiment - it would be an error. What I am saying is that the time difference presented here is obvious to the naked eye. Even if you completely remove the millies and just keep time with a watch, it would give similar results. The difference in time between nano and millies is not that huge, and quite frankly, I have never seen a fluctuation of over 1/500 cycle (not to mention 1/50 like you suggest), it would need an exceptionally bad situation for something like that to occur. – Ordous May 14 '14 at 11:57
  • Possible duplicate of http://stackoverflow.com/questions/751105/why-does-the-debugged-program-slow-down-so-much-when-using-method-entry-debuggin – apangin May 14 '14 at 19:51
  • do not try to turn it on when you start the application! – Alex78191 Sep 19 '19 at 19:39

2 Answers2

9

Recently I made a research regarding Method Breakpoint Slowness issue. My conclusion was that the root issue is that Method Breakpoints are implemented by using JDPA Method Entry & Method Exit feature. This implementation requires the JVM to fire an event each time any thread enters any method and when any thread exits any method.

click here to read the entire article

Smartik.NET
  • 136
  • 1
  • 4
0

According to Eclipse Help

While the breakpoint is enabled, thread execution suspends before that line of code is executed. The debugger selects the thread that has suspended and displays the thread's stack frames. The line where the breakpoint was set is highlighted in the editor in the Debug Perspective.

So according to me this may be the reason of this delay.

akash
  • 22,664
  • 11
  • 59
  • 87
  • 1
    Is it because _finding the thread that is executing before start executing a method_ is more complex than just _stooping the thread that is executing a method_? – user454322 Mar 02 '16 at 07:11
  • 1
    More from IntelliJ: https://intellij-support.jetbrains.com/hc/en-us/articles/206544799-Java-slow-performance-or-hangups-when-starting-debugger-and-stepping – BamaPookie Mar 09 '17 at 18:04