Input Program | Original size | After shrinking | After optim. | After obfusc. | Total reduction | Time | Memory usage |
---|---|---|---|---|---|---|---|
ClassPath, the GNU runtime library | 2.0 M | 2.0 M | 1.9 M | 1.9 M | 4 % | 31 s | 39 M |
Worm, a sample midlet from Sun's J2ME | 9.9 K | 9.4 K | 9.3 K | 8.1 K | 17 % | 2 s | 13 M |
ProGuard itself | 404 K | 364 K | 361 K | 231 K | 42 % | 21 s | 35 M |
JDepend, a Java quality metrics tool | 57 K | 36 K | 35 K | 30 K | 48 % | 8 s | 24 M |
Tomcat, the Apache servlet container | 1.2 M | 538 K | 528 K | 363 K | 68 % | 20 s | 39 M |
JavaNCSS, a Java source metrics tool | 624 K | 243 K | 235 K | 158 K | 74 % | 13 s | 35 M |
Ant, the Apache build tool | 2.3 M | 276 K | 265 K | 203 K | 91 % | 20 s | 49 M |
Results were measured with ProGuard 3.0 on a 2.6 GHz Pentium 4 with 512 MB of memory, using Sun JDK 1.4.2 in Fedora Core 1 Linux.
The program sizes include companion libraries. The shrinking step produces the best results for programs that use only small parts of their libraries. The obfuscation step can significantly shrink large programs even further, since the identifiers of their many internal references can be replaced by short identifiers.
Timings are mainly governed by the fixed overhead of reading jars and initializing data structures. The actual shrinking, optimization, and obfuscation are typically fast in comparison.
Memory usage (the amount of physical memory used by ProGuard while processing) is governed by the basic java virtual machine and the total size of the library jars and program jars.