You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In one project, we use an obfuscation dictionary with 10,000 entries. We found that most CPU time was spent in proguard.obfuscate.DictionaryNameFactory.nextName.
It turns out we had more than 10,000 symbols to obfuscate in the project and ran out the dictionary. DictionaryNameFactory falls back to generating fresh names and checking them against the dictionary so it doesn't generate a duplicate, but this duplicate-checking uses a linear scan (List#contains, line 255), so our large dictionary was causing this code path to be very slow.
In one project, we use an obfuscation dictionary with 10,000 entries. We found that most CPU time was spent in
proguard.obfuscate.DictionaryNameFactory.nextName
.It turns out we had more than 10,000 symbols to obfuscate in the project and ran out the dictionary.
DictionaryNameFactory
falls back to generating fresh names and checking them against the dictionary so it doesn't generate a duplicate, but this duplicate-checking uses a linear scan (List#contains
, line 255), so our large dictionary was causing this code path to be very slow.proguard/base/src/main/java/proguard/obfuscate/DictionaryNameFactory.java
Lines 250 to 255 in 3a9b11b
The text was updated successfully, but these errors were encountered: