Seting a breakpoint directly on a method declaration in IntelliJ IDEA can cause severe application startup delays when launching in debug mode. In a minimal test project, startup time jumped from 1.7 seconds to 35 seconds after introducing a single method breakpoint—an increase of roughly 2000%. This behavior is consistently reproducible with breakpoints placed on Mapper interfaces, though it may appear intermittently on other methods. IDEA does display a warning about debug performance when a method breakpoint is active, but the notification is easy to overlook.

The root cause lies in how the Java Platform Debugger Architecture (JPDA) implements method breakpoints. They rely on Method Entry and Method Exit events. The JVM is required to fire an event every time any thread enters or exits any method. This effectively creates a broad instrumentation mechanism similar to AOP at a very low level. The event chain flows from the IDE to the front-end debugger, through the agent to the VM, and back to the IDE on every single method transition. The IDE then checks its internal breakpoint list; if the current method matches, a SetBreakpoint request is issued. Otherwise, the thread resumes. The sheer volume of events generated during application startup is what causes the dramatic slowdown.

A recommended mitigation is to disable the Method Exit event on the breakpoint. Testing showed that deactivating the exit event reduced startup time from 113 seconds to 46 seconds in a sample scenario. Right-clicking a method breakpoint exposes the entries Method Entry and Method Exit, both enabled by default. Unchecking Method Exit cuts the number of fired events roughly in half.

For teams encountering mysterious debug-mode slowness, verifying the absence of method breakpoints is straightforward. Use View Breakpoints in IDEA to inspect all breakpoints in the project, specifically checking the Java Method Breakpoints category. Any listed method breakpoint should be removed unless absolutely necessary. As an alternative, the IDE’s project files can be inspected: inside workspace.xml (or the legacy .iws file), look for a method_breakpoints node or a breakpoint_rule element related to method patterns. Remove the corresponding entries.

While method breakpoints are powerful—especially for debugging interface methods with multiple implementations—their performance impact warrants cautious use. A practical workaround is to rely on regular line breakpoints within method bodies wherever possible. The feature's design has been a known issue since at least 2008, repeatedly causing confusion when applications behave inconsistently across run and debug modes. Side effects can also arise from IDEA’s automatic rendering of collection classes and toString() calls during debugging. For example, invoking toString on certain collection implementations can mutate internal state, leading to different results between direct execution and debug sessions. Disabling Enable alternative view for Collections classes and Enable toString() object view under Debugger Data Views prevents such unintended side effects.