34

Whenever adding a breakpoint to the line of a method declaration (in Intellij IDEA or Android Studio), a popup appears:

Method breakpoints may dramatically slow down debugging

Why would it dramatically slow down debugging, is my question? What is different about putting the breakpoint on the first line of the function?

Thanks!

Jeeter
  • 5,887
  • 6
  • 44
  • 67
  • See http://stackoverflow.com/questions/751105/why-does-the-debugged-program-slow-down-so-much-when-using-method-entry-debuggin – Javaru Jun 26 '15 at 16:40
  • Does this answer your question? [Intellij Debugger slow: Method breakpoints may dramatically slow down debugging](https://stackoverflow.com/questions/27966065/intellij-debugger-slow-method-breakpoints-may-dramatically-slow-down-debugging) – SamB Feb 06 '20 at 22:14

3 Answers3

13

I looked around a little, and saw this post in the Intellij Documetation:

Method Breakpoint

Method breakpoints act in response to the program entering or exiting a particular method. They let you target your debugging sessions by method you wish to investigate, rather than by line number. Method breakpoints let you follow the program flow at the method level as well as check entry and exit conditions. Note that using method breakpoints can slow down the application you are debugging.

I guess it stops the program right before it enters the method, so that you can evaluate the parameters and such before entering the method.

The reason it dramatically slows down is (This is what I can gather, because that is all I could find on method breakpoints in Intellij's documentation) that it has to:

let you follow the program flow at the method level as well as check entry and exit conditions

and I suppose that would take a lot longer than just halting the program's execution

Community
  • 1
  • 1
Jeeter
  • 5,887
  • 6
  • 44
  • 67
  • 2
    Please use the edit link on your question to add additional information. The Post Answer button should be used only for complete answers to the question. – dhh Jun 26 '15 at 05:02
  • The thing is, intellij's docs are extremely sparse when it comes to this. I looked through their documentation, and tried to answer my question to the best of my abilities with what I had to work with. This seemed like the most complete answer I could get – Jeeter Jun 26 '15 at 05:04
  • 7
    I think this does qualify as a valid answer to his question though; and judging by the [help center](http://stackoverflow.com/help/self-answer) a perfectly valid use of this site. – user4989692 Jun 26 '15 at 06:56
  • 3
    @dhh From the [help center](http://stackoverflow.com/help/how-to-answer): "Help us find a solution by researching the problem, then contribute the results of your research and anything additional you’ve tried as a partial answer. That way, even if we can’t figure it out, the next person has more to go on. You can also vote up the question or set a bounty on it so the question gets more attention... Any answer that gets the asker going in the right direction is helpful, but do try to mention any limitations, assumptions or simplifications in your answer. " – Jeeter Jun 26 '15 at 15:34
0

My understanding is that the code must be run interpretively (instead of using JIT to pre-compile?) when the breakpoint is set on method entry.

If you set the breakpoint on the first line of the method instead, I suspect a line number index into the code can be used to simply swap a break opcode for the original opcode, so the app runs full speed. (which still seems pretty slow to me when debugging ;)

Taryn
  • 1,670
  • 1
  • 15
  • 22
0

There is a simple explanation from the IntelliJ Team: "Method breakpoints will slow down debugger a lot because of the JVM design, they are expensive to evaluate"

https://intellij-support.jetbrains.com/hc/en-us/articles/206544799-Java-slow-performance-or-hangups-when-starting-debugger-and-stepping

Átila Braga
  • 43
  • 7
  • 1
    https://stackoverflow.com/a/54995643/4130619 claims that "This implementation requires the JVM to fire an event each time **any** thread enters **any** method and when **any** thread exits **any** method." – reducing activity Jul 27 '19 at 06:51
  • Well, it was clearly design and/or implementation: we want to know some specifics about what, in particular, ends up eating the CPU. – SamB Feb 06 '20 at 22:12