Java: slow performance or hangups when starting debugger and stepping
Debugger performance problems usually come from one of two things. Some breakpoint types make the JVM report a very common event, which slows the whole program while it runs freely, including startup. Other settings only affect how fast the debugger inspects values while it is paused or stepping. The two groups have different fixes, so it helps to know which one you are hitting.
Quick check: is a breakpoint the cause?
If the slowdown appears during startup or while the program runs freely, not only when you step, first isolate a breakpoint:
- Toggle Mute Breakpoints in the Debug tool window and start the session again.
- If startup is fast with breakpoints muted, one of the breakpoint types below is responsible.
- Open Run | View Breakpoints (Ctrl+Shift+F8, or Cmd+Shift+F8 on macOS) to review and remove them.
Breakpoints that slow the whole program, including startup
These make the JVM fire an event on operations that happen constantly, so they slow code even while it runs freely, not just when you step.
- Field watchpoints (also called field breakpoints) ask the JVM to report every access or modification of a field. This has a global cost. It can turn off JIT optimizations and send field access through a slow path across the whole program, so a single watchpoint on a frequently used field can make startup many times slower. Even one you set earlier and forgot about is enough. Remove or disable watchpoints you no longer need. In Run | View Breakpoints they are grouped under Java Field Watchpoints.
-
Method breakpoints slow the debugger a lot because of the JVM design, they are expensive to evaluate. Remove method breakpoints and consider using regular line breakpoints instead. To confirm you have none, open the
.idea/workspace.xmlfile in the project root (or the<project>.iwsfile if you use the old project format) and look for entries in themethod_breakpointsnode. - Exception breakpoints set on Any exception, or a broad caught exception, fire every time an exception is thrown or caught. Frameworks such as Spring throw and catch many exceptions during startup, so this alone can add minutes. Restrict the exception breakpoint to a specific exception class, or disable it.
Settings that slow stepping and value inspection
These affect the debugger only while it is paused or stepping. They do not slow a freely running program, so they are not the cause of a slow startup.
- Show method return values is enabled in the Debug tool window. Try disabling it to improve performance.
- Enable alternative views for Collections classes and Enable toString() object view in Settings | Build, Execution, Deployment | Debugger | Data Views. If toString() methods take a long time to complete, disable this option. Note that custom toString() methods can also change the behavior of the application under the debugger if the code inside them changes the state of your application.
- Memory tab in the Debug tool window updates on every debugger stop. Minimize it to improve stepping performance.
- Settings | Build, Execution, Deployment | Debugger | Data Views | Editor | Show values inline. Disable to improve performance.
- Settings | Build, Execution, Deployment | Debugger | Data Views | Java | Predict condition values and exceptions based on data flow analysis. Disable to improve performance.
- Mute Renderers option in the Debug tool window Variables view context menu.
See also
Please sign in to leave a comment.
this whole document does not even work
https://www.jetbrains.com/help/idea/running-and-debugging-typescript.html
the ide is loadinf main.js inadvertently and other typescript JS files inadvertently into the IDE from beneath the webpack ./// directory
the threads with this product and its debugging typescript are enormous
Still cannot get this product to properly debug and live reload typescript changes in any cohetrent functional maner after having purchaSED IT FOR 3 years steady
bottom line is this product still cannot navigate JS to TS at all
they technicians are nto qualifying their product on a real world application setup
a plain angular app running on local host does not cut it
try to build an app on https and run it with real worl URL
and you will see the logic defaults to never ending loading of main.js into the IDE and breakpoints landing in the JS file instead of the TS file
typescript is not debuggable with latest jetbrains webstorm
I have exhausted all permutations of edit configurations
the Angular CLI edit configuration options appears to be there for show... doesnt even debug
setting all kinds of urls to various folders within the debug config fails for realworld urls and webpack:///./src urls
trying to attach to a live chrome app fails too
please submit a request using the button below
i forgot that in macbook pro you must add your hostname to the /etc/hosts. it solved the freezes.
Got a couple of suggestions
Thanks, typo is fixed. I'm not sure I understand your first suggestion, please clarify.
Oh, I meant bringing up the actions tab for everything that you can do on `IntelliJ`. To get breakpoints, builds, settings, preferences,...
None of these worked for me and I did every single one of these plus, adjusted memory settings, adjusted emulator settings, I have read at minimum a dozen to two dozen articles surrounding this issue, and have followed every single recommendation here and elsewhere (e.g., stackoverflow).
I'm tired of workarounds. Workarounds are just that... workarounds are not solutions! I have also noticed that all workarounds for this issue eventually fail, like the disabling of the "toString()" in debug settings. It worked for a day then never worked again. Case and point, I performed every single one of the above suggestions and it seemed to work for about an hour of constant debugging and after that, failed on every instance of a Collection type.
In my case, every form of Collections (i.e., String[], int[][, List, ArrayList, HashMaps, etc.) are impacted. That tells me there is a resource management issue and could be memory, byte, buffering management or cleanup etc. Hanging issues, in my experience, always seem to fall around these types of resource management. As I mentioned, the one consistent observation in my case is that this falls very close to 100% failure on Collections objects. This does not occur on other objects or primitives.
very cool brother one
I'm switching back to Eclipse. Even very simple statements cannot be executed line by line by pressing F8 because it takes 3 seconds even for simple assignments. I'm not going to renew my subscription
Debugging one of my webapps makes it extremely slow, to the point that requests time out. Zero breakpoints.