Why Method Breakpoints Slow Down Your Java Debugging by 2000% (And How to Fix It)

I spent several hours troubleshooting a mysterious slowdown when launching a Java project in Debug mode, only to discover that a single method breakpoint was the culprit.

When starting a project in Debug mode, never set breakpoints on methods!

Method breakpoints are set on the line containing the method declaration. In IntelliJ IDEA you can view all breakpoints via View Breakpoints , where the Java Method Breakpoints checkbox lists them.

Enabling a method breakpoint caused my simple project to take 35 seconds to start, compared with 1.75 seconds without it—a 2000% increase.

After reproducing the issue on a colleague’s machine, I learned that the slowdown is caused by the JVM’s handling of method breakpoints. The official JetBrains article states:

Method breakpoints will slow down debugger a lot because of the JVM design, they are expensive to evaluate.

The underlying reason is that method breakpoints are implemented using JPDA’s Method Entry and Method Exit events, which fire for every thread entering or exiting any method, creating massive overhead.

To verify and remove method breakpoints you can inspect the .idea/workspace.xml file for a method_breakpoints node, or simply delete them via the IDE UI.

Not all method breakpoints cause the issue; the problem is reproducible when the breakpoint is placed on a Mapper interface method, but not on many other methods.

JetBrains also warns that the debugger will display a popup about the performance impact, which many developers ignore.

Why Does This Happen?

The JPDA (Java Platform Debugger Architecture) requires the JVM to generate an event for every method entry and exit, which the debugger processes to check if a breakpoint is set. This massive event stream dramatically slows down startup.

Research by Gabi ("Method Breakpoints are Evil") confirms that the root cause is the JPDA implementation using Method Entry/Exit, effectively turning the breakpoint into an AOP‑like interceptor.

Key conclusions from the research:

Method breakpoints are an IDE feature, not a JPDA feature.

They are genuinely performance‑evil.

They severely impact debugging speed.

Use them only when absolutely necessary.

If you must use them, consider disabling the Method Exit event.

Disabling the Method Exit event reduced startup time from 113 seconds to 47 seconds in my test.

Unexpected Gains

While exploring the official JetBrains documentation, I found useful debugging tips for Java Streams and concurrency.

For Streams, the IDE can show the call stack and variable values at each step. The following code finds prime numbers up to 100 and demonstrates how to set a breakpoint in isPrime to locate a bug:

<code>class PrimeFinder {
    public static void main(String[] args) {
        IntStream.iterate(1, n -> n + 1)
                .limit(100)
                .filter(PrimeTest::isPrime)
                .filter(value -> value > 50)
                .forEach(System.out::println);
    }
}

class PrimeTest {
    static boolean isPrime(int candidate) {
        return candidate == 91 ||
               IntStream.rangeClosed(2, (int) Math.sqrt(candidate))
                        .noneMatch(n -> (candidate % n == 0));
    }
}
</code>

For concurrency, the IDE can pause both the main thread and a worker thread at a shared breakpoint, allowing you to inspect the state of a synchronized list and see why duplicate entries appear.

<code>public class ConcurrencyTest {
    static final List a = Collections.synchronizedList(new ArrayList());

    public static void main(String[] args) throws InterruptedException {
        Thread t = new Thread(() -> addIfAbsent(17));
        t.start();
        addIfAbsent(17);
        t.join();
        System.out.println(a);
    }

    private static void addIfAbsent(int x) {
        if (!a.contains(x)) {
            a.add(x);
        }
    }
}
</code>

By right‑clicking the breakpoint and selecting “Thread”, you can view each thread’s stack frames and observe the race condition.

Debugging Gotchas

Another subtle issue is that IntelliJ automatically calls toString() on collections during debugging. Some collection implementations modify internal state in toString() , causing the program’s behavior to differ from a normal run.

The fix is to disable the two renderer options under Settings → Build, Execution, Deployment → Debugger → Data Views → Java → Enable alternative view for Collections classes and Enable alternative view for Maps classes .

After disabling them, the debugger shows raw collection data without invoking potentially state‑changing toString() methods.