-
Notifications
You must be signed in to change notification settings - Fork 4.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[core] Jadx-gui consumes a lot of resources when decompilation is completely finished #1000
Comments
@sergey-wowwow can you check cpu usage using any profiler (like VisualVM)? P.S. jadx hit 1000 issues! Yay! 😆 🎉 |
@skylot |
@sergey-wowwow |
@skylot My Java version:
|
@sergey-wowwow can you try disable memory usage bar (View -> Show memory usage bar). |
@skylot |
- disabled by default - update only if label changed - skip updates if app window becomes inactive
@sergey-wowwow looks like my guess was not correct ( |
Hi @skylot. I can confirm I was suffering a significant CPU performance hog with jadx-gui (v1.1.0, where the memory usage bar was not disabled by default yet) in macOS using Java 14.0.1 (default version in macOS Catalina) while the GUI is displayed in the screen. By simply minimising the application, the CPU gets relaxed again... I have tried disabling the memory usage bar, as suggested above, and the issue completely disappeared, so your hypothesis is correct in my case. As soon as I show the bar again, the CPU party re-starts... ;-D |
@raulsiles Can you please check Jadx using VisualVM what thread is causing this? In VisualVM open the tab "Sampler" and start data collection using the "CPU" button. On an totally idle Jadx no thread should be displayed. But as you encounter CPU usage you should see one or more threads that are consuming CPU time. If you have one ore more you can click on the plus sign before the thread name to expand the view and see what Java methods are currently executed. If you could post this data this would be really helpful. |
Hi @jpstotz: In the "CPU samples" tab however, the "Forward calls" display the Java methods in the attached images, with huge RMI TCP connection usage, and some AWT. The CPU usage switches between the two RMI TCP connections threads after a few seconds, in an alternate way: one, and then, the other, and back to the previous one... |
@raulsiles The RMI TCP connection should not be the problem source. They should be caused by VisualVM retrieving the JVM internal data periodically. What makes me wonder is that you observe two of them. The version you used for generating this data is v1.1.0 or have you used the latest unstable version that already contains skylot's fixes? |
Hi @jpstotz. Yes, I used on purpose v1.1.0 as this is the version I originally found the issue in. AFAIK, the fix skylot introduced in v1.2.0 is to hide by default the memory usage bar to avoid this issue. I've tried with v1.2.0 and I can confirm the issue persists if you enable the bar back (if you need it, I can collect the CPU samples via VisualVM with the latest version). |
@skylot I have double checked the CPU peaks are still prevalent in the latest build from Jan 15, 2020, jadx-1.2.0-b1479-a3ea5145, as soon as the view for the Memory Usage Bar is enabled. Perhaps this issue should be reopened to work on a future definitive fix for it (apart from the partial fix of hiding the Memory Usage Bar, that BTW works like a charm). |
@raulsiles I am sorry but the last days I investigated this issue a bit deeper. The most obvious effect of this issue is that using VisualVM on Jadx while the HeapUsageBar is active is that every second the heap usage increases by about 4 MB (at least on my test system). To track down the cause I uncommented every piece of code in the class The first one was:
Don't ask my why, when this line is uncommented the CPU is active and the memory usage continuously rises. The second line that activates this issue is:
If the method This brings me to the conclusion that there is nothing we can do to fix this problem. It is obviously a bug in Java. But the bigger problem is that there is no real workaround as |
Wow @jpstotz! Thanks for your really detailed analysis! Based on your conclusions, if possible, then jadx-gui needs to get rid of the FocusManager, and replace the JProgressBar with another GUI Swing component (if it exists) not presenting that weird behaviour :( I agree that not printing any text in the progress bar reduces its main purpose. Perhaps printing the string details only when you hover over or click in the progress bar could be another workaround. |
When I have an app opened in jadx-gui, battery of my laptop is flying away :D Probably it's a bug, and something continues consuming CPU resources
The text was updated successfully, but these errors were encountered: