This is the mail archive of the java@gcc.gnu.org mailing list for the Java project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Obfuscation - optimisation?


Hello!

When using classes one can use obfuscation/optimisation
tools on class-files (e.g. progaurd) in order to reduce
footprint,
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.
Ah, now I understand.  Embedded devices, presumably not using virtual
memory.  On a machine that does use virtual memory using such a
system would make no sense at all, but if you want to squeeze such
stuff into flash it might.
Hopefully yes! :-)
And maybe in memory footprint? I don't quite know how the memory-model/behaviour is.
Say, I will most probably have several hundred instances of some class (and subclasses) in memory. Will these take up more space if all their longAndNice()-names are decimated to smaller ones?


Mind you, in that case you might as well compress the data on the flash device. Unless you want XIP, of course.
I am - I'm using jffs2...
So if there is no memory-footprint-advantage, I'll probably abandon the idea...
Of course, there is still the advantage in the smaller size of application-firmware file, but that's secondary...


Regards,
 Martin


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]