Java: slow performance or hangups when starting debugger and stepping

Debugger performance can be affected by the following:

  • Method breakpoints will slow down debugger a lot because of the JVM design, they are expensive to evaluate. Remove method breakpoints and consider using the regular line breakpoints. To verify that you don't have any method breakpoints open .idea/workspace.xml file in the project root directory (or <project>.iws file if you are using the old project format) and look for any breakpoints inside the method_breakpoints node.
  • Show method return values option is enabled in the Debugger tool window. Try disabling this option to improve the performance.
  • Enable alternative views for Collections classes and Enable toString()’ object view options enabled in Settings (Preferences on macOS) | 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 semantics of the application when running under debugger in case the code inside these methods changes the state of your application.
  • Memory tab in the debugger toolwindow. It is updated on every debugger stop, try to minimize it to improve stepping performance.
  • Settings (Preferences on macOS) | Build, Execution, Deployment | Debugger | Data Views | Editor | Show values inline. Disable to improve performance.
  • Settings (Preferences on macOS) | Build, Execution, Deployment | Debugger | Data Views | Java | Predict condition values and exceptions based on data flow analysis. Disable to improve performance.
  • Enable Mute Renderers option in the Debug tool window Variables view context menu.

See also the following help sections:

79 out of 205 found this helpful
41 comments

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

0

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

 

 

0

trying to attach to a live chrome app fails too

0

please submit a request using the button below

0

i forgot that in macbook pro you must add your hostname to the /etc/hosts. it solved the freezes.

0

Got a couple of suggestions

  • why not refer to anyone using the actions command on the IDE and so this brings up all the breakpoints present in the application.
  • Also there's a type on this article - `verity` to be changed to `verify`.
0

Thanks, typo is fixed. I'm not sure I understand your first suggestion, please clarify.

1

Oh, I meant bringing up the actions tab for everything that you can do on `IntelliJ`. To get breakpoints, builds, settings, preferences,...

0

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.

0

very cool brother one

0

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

0

Please sign in to leave a comment.

Have more questions?

Submit a request