-
Notifications
You must be signed in to change notification settings - Fork 394
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
Poor performance with larger code base #283
Comments
Hi @davidgiga1993 ! Great to hear you're a long time user of ProGuard! There are a couple of issues reported with performance reduction already (#79 #91) but there was never any conclusion or reproducible sample.
An easy way to narrow down the timing of each feature is to pass the log output through the
We don't have any specific plans but if you can provide some reproducible sample and we can narrow down the issue that will be a good start for solving any performance problems. |
Thanks for the fast reply! Similar to the other issues, providing a sample will be a bit tricky since it's the IP of my company, but since each optimization step takes so long, would it be possible to (privately) provide the application jar after one pass of obfuscation? Also as a sidenode, when building the app for android, R8 takes about 2 minutes with the same proguard config file.
|
I did a bit more profiling and it looks like the most time is spent in |
Nice work tracking that down! |
I originally gave InstructionOffsetValue an array of ints instead of a HashSet of Integers because the array typically only contains one or two elements and there are many instances of them during the
abstract evaluation of a method. So my goal was to keep the memory use and garbage collection in check. Automatically generated code with huge switch/case statements breaks the assumption. You should
perhaps check the increase in memory use for large methods.
|
Hi @davidgiga1993 ! Thanks for your contribution. The fix you made is now in ProGuard 7.3.1. |
Hi,
I'm using proguard for nearly 10 years now and so far I never had any major performance issues. However at some point proguard got extremely slow - I can't recall the exact time and I assume it's related to the bytecode input. It takes about 25 minutes to obfuscate a java desktop application with about 400kLoc on an Mac Mini M1.
I've also tested it on an Windows 11 Ryzen 5950x and it took 22 minutes. Most of this time only 1 core is used, sometimes 2 for a short period.
The project is currently using
com.guardsquare:proguard-gradle:7.2.2
with gradle 7.5 and temurin jdk 17 with 1.8 as compile target.The app uses quite a bit of autogenerated code with huge switch/case statements, and I somehow suspect that it could be related to that, howver I haven't verified it yet.
My questions are:
Happy to get any feedback on this topic. In the meantime I'll try to remove the auto generated code and see if it makes a difference.
For reference, here is the proguard config and output of the M1 build:
The text was updated successfully, but these errors were encountered: