The table below presents some typical results:
Input Program | Original size | After shrinking | After obfusc. | Total reduction | Time | Memory usage |
---|---|---|---|---|---|---|
ClassPath, the GNU runtime library | 2.2 M | 2.2 M | 1.9 M | 13 % | 22 s | 30 M |
Worm, a sample midlet from Sun's J2ME | 9.9 K | 9.5 K | 8.3 K | 16 % | 1 s | 9 M |
JDepend, a Java quality metrics tool | 60 K | 40 K | 32 K | 46 % | 5 s | 16 M |
ProGuard itself | 182 K | 151 K | 92 K | 49 % | 6 s | 18 M |
Tomcat, the Apache servlet container | 1.2 M | 542 K | 377 K | 68 % | 10 s | 28 M |
JavaNCSS, a Java source metrics tool | 640 K | 248 K | 168 K | 74 % | 9 s | 23 M |
Ant, the Apache build tool | 2.4 M | 280 K | 212 K | 91 % | 11 s | 38 M |
Results were measured with ProGuard 1.6 on a 2.4 GHz Pentium Xeon with 1 GB of memory, using Sun JDK 1.3.1 in Debian Linux.
The program sizes include companion libraries. Programs that only use small parts of their libraries benefit the most from the shrinking step.
Timings are mainly governed by reading and parsing library jars and program jars. Shrinking and obfuscation is typically very 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.