Re: Obfuscation - optimisation?

[Martin Egholm Nielsen <martin at egholm-nielsen dot dk>]

Hi there,

> > > > When using classes one can use obfuscation/optimisation tools
> > > > on class-files (e.g. progaurd) in order to reduce footprint,
> > But that is then the way to go - obfuscation on class-basis and
> > then straight ahead?!
> Well, what do you want to achieve?  All that "obfuscation" would do
> in the gcj context is break debugging.
Well, it would make all classes significant smaller - at least it does 
in the class-file situation. All the niceAndDescriptiveMethodName() 
methods and fields will have their names decimated into something that 
does not take up so much space.
Hence, the final program will have a smaller footprint when fitting it 
into an embedded device with not that much flash. And I assume that 
there will some effect in memory usage, as well - maybe not...

> It says here:
> "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.
Bingo! :-)

> "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."
Well, these are comments regarding running proguard - has nothing to do 
with the final program...

Best regards,
 Martin