Results

ProGuard shrinks and obfuscates jars quickly and effectively. The gains of removing dead code obviously depend on the original code. If you're using libraries, you'll really benefit from the shrinking phase. The further gains of removing debug code and obfuscating (typically replacing long names by short names), are on the order of 20%.

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.


Copyright © 2002-2003 Eric Lafortune.