From: Jeff P. <jcp...@ro...> - 2010-09-01 15:24:14
|
I have used Proguard, and it definitely can delete things below Class level, so I am not sure what you mean about method-level optimizations. If you add the '-printusage filename' to your config or Ant build.xml you can see everything removed. A class name by itself means the whole class was delete. If it is followed by a colon, only the stuff below was removed along with line numbers, e.g. myNamespace.com.stuff.morestuff.CurrentPlatform: public static final byte SERVER_PLATFORM public static final byte DESKTOP_PLATFORM public static final byte PHONE_PLATFORM 32:32:public static boolean isServer() 34:34:public static boolean isPhone() 39:39:public static boolean isValidPlatform(byte) 40:40:public static boolean isValidClientPlatform(byte) It also does much optimization in the methods themselves. Probably the one that should be of most interest to you is method in-lining. Sounds like you only want to do this when the space penalty is very low. This can be adjusted using system properties, only documented within Proguard's source code. The package to look at is proguard.optimize.peephole . The Class is MethodInliner. You will see that there are 2 properties consulted for the maximum resulting code length to decide if it should be done. One for J2SE & the other for J2ME. Specifying a lower value for the J2SE version might help. Looking through the source of this entire directory for other system properties may also be good. I know of another way to get the size down, but think they are going to be sort of "empty calories". Here it is just in case: use option '-repackageclasses ${single-package}'. Use something like '<property name="single-package" value="_"/> Hope this helps On 8/31/10 5:07 PM, "Panayotis Katsaloulis" <pan...@pa...> wrote: > On 31 Αυγ 2010, at 8:44 μ.μ., Sascha Haeberling wrote: > I am actually > working on such an optimized call graph dependency optimizer, which should > shrink down the whole compilation size. > > In addition we will remove the > need to compile classes that don't need to be compiled. E.g. all the JDK > classes need to be compiled once and we can provide it to our users. These two > measures should speed up compilation time a lot. > > // Sascha The problem > has to do more with size, not time. It is really easy to produce static > libraries, and thus reduce compilation time to minimum. The way it is done > right now, though, is again object-level optimization - similar to what > ProGuard does (and it does it extremely well - it is even able to deal with > simple reflection cases). The problem is with method-level optimizations. > That is why I propose to investigate such methods. In which level is the > optimization you are working > on? -------------------------------------------------------------------------- > ---- This SF.net Dev2Dev email is sponsored by: Show off your parallel > programming skills. Enter the Intel(R) Threading Challenge > 2010. http://p.sf.net/sfu/intel-thread-sfd ___________________________________ > ____________ xmlvm-users mailing > list xml...@li... https://lists.sourceforge.net/lists/lis > tinfo/xmlvm-users |