Re: Obfuscation - optimisation?

[Doctor Bill <docbill at gmail dot com>]

I should learn to try something before opening my mouth.  I had always
been told Obfuscation only had a small side benefit in code size
reduction.  However,  I tried it on a 192kb applet I wrote, and just
the obfuscation step reduced the jar file to 162kb.

And while the other steps also had an effect, none of them resulted in
working code.  If they had worked, the reduction size would have been
another 20kb.  Meaning obfuscation by far was the most significant way
to reduce the file size.

However, one thing still puzzles me.   What does this have to do with
gcj?  While I am certain an optimization flag could be added and code
from something like proguard could be merged, it seems to me the more
important thing right now is just a fully stable compiler and API
classes.  Obfuscation can always run as a separate step, regardless of
what java compiler is used.

Bill



On Wed, 24 Nov 2004 14:13:06 -0500, Doctor Bill <docbill@gmail.com> wrote:
> On Wed, 24 Nov 2004 12:08:38 +0000, Andrew Haley <aph@redhat.com> wrote:
> > Martin Egholm Nielsen writes:
> > "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.
> 
> I wish I knew what you were actually quoting.  In any event, this
> description ignores the main point of obfuscation is not to reduce
> program size, but to make a reverse compile of the program more
> difficult to read.  Meaning even if someone uses a reverse compiler
> like JAD they will not be able to determine as much about your
> original source code than when it used meaningful descriptive names.
> 
> File reduction is just a side benefit of obfuscation, that usually
> happens.  If you already used short non-descriptive names it is quite
> possible obfuscated names will be longer, resulting in an increase in
> file size.
> 
> However, typically you achieve better compression on names with some
> sort of pattern to them, than completely random names.  So you may
> also find even if the class files end up smaller, the jar file becomes
> larger or stays the same size.
> 
> For the most part obfuscater for reduction is only really good when
> you are facing some hard limit that you just barely exceed.  For
> example, some mobile phones will only load jar files less than 50KB.
> So if you have a 51KB jar file, than it might be a good idea to try
> obfuscating instead of rewriting your code to compile slightly
> smaller.
> 
> Bill
>