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

Hello, I'm Su San. Last week I wasted several hours on a puzzling debugging issue.

When launching a project in Debug mode locally, never set breakpoints on methods! Never!

Method breakpoints are set on a method line and can be viewed via the IDE's "View Breakpoints" dialog, which lists all breakpoints including "Java Method Breakpoints".

When a project runs in Debug mode with method breakpoints, startup time can increase dramatically. In a simple project, startup went from 1.753 seconds to 35.035 seconds—a 2000% increase.

The problem was reproduced by adding a method breakpoint to a Mapper interface; other methods did not consistently show the slowdown.

Investigation revealed that the IDE shows a warning that method breakpoints can cause slow debugging.

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

The official solution is to remove method breakpoints and use regular line breakpoints.

Remove method breakpoints and consider using the regular line breakpoints.

To verify no method breakpoints remain, check the .idea/workspace.xml file for a method_breakpoints node.

Method breakpoints are implemented using JPDA's Method Entry & Method Exit events, which fire for every thread entering or exiting any method, causing a large number of events and performance degradation.

IDE adds breakpoints to its internal list.

IDE enables Method Entry & Exit events.

Debugger forwards requests to the VM.

Each event is processed and forwarded back to the IDE.

IDE checks if the method is in its breakpoint list.

If so, a SetBreakpoint request is sent; otherwise the thread continues.

Disabling the Method Exit event reduced startup time from 113 seconds to 46 seconds in a test.

Additional debugging tips include using IDEA's Stream debugging example and a concurrency example, both with code snippets:

<code class="language-java">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>

And a concurrency test:

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

    public static void main(String[] args) throws Exception {
        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>

Further investigation of JetBrains' official article confirms that method breakpoints rely on JPDA (Java Platform Debugger Architecture) and that the massive event generation is the root cause of the slowdown.

Recommendations: use method breakpoints only when necessary, consider disabling Method Exit events, and prefer line breakpoints for routine debugging.

Additional IDE settings that can affect debugging performance include collection rendering options; disabling them can prevent unexpected side‑effects from toString() calls.