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.
|
// Return the next different name from the other name factory. |
|
do |
|
{ |
|
name = nameFactory.nextName(); |
|
} |
|
while (names.contains(name)); |
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.
DictionaryNameFactoryfalls 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