Menu
▾
▴
Re: [xmlvm-users] One small XMLVM benchmark
|
From: Steve H. <st...@we...> - 2012-12-07 21:26:52
|
Shai confirmed that they do not use Proguard for their builds. http://www.codenameone.com/discussion-forum.html?place=msg%2Fcodenameone-discussions%2FrFAJLbMDcPI%2FIBIPo_Fx8ywJ If I find time and curiosity, perhaps I'll do some experimentation to see how proguard affects the performance. Shai's point that LLVM already does quite good job of optimization leads me to think that there probably isn't a whole lot to be gained. But hey, I was wrong in my first assumption that Avian would be significantly faster than XMLVM. So what do I know? -Steve On Fri, Dec 7, 2012 at 10:09 AM, Steve Hannah <st...@we...> wrote: > Thanks for the tips. Avian used pro guard but had optimizations disabled > because I was getting errors otherwise, > > I don't know if the xmlvm build used proguard because I used their build > server for that one. I will check with Shai to see if they're using > proguard and what the settings are. > > Steve > > > On Friday, December 7, 2012, Jeff Palmer wrote: > >> Hi, >> >> Might it not help pre-running byte code through Proguard with the number >> of optimization passes set to say 5? Some of these static accesses might >> not even survive the process. The nice thing might be that xmlvm does not >> have to change. Also you can check the the performance impact with or >> without. >> >> On the blog, it said proguard was used for the Avian Port. This was for >> size, but was the xmlvm version also pre-run through Proguard? >> >> Here is some output, pass 1, from a desktop application. Am noticing >> that staticized methods is part of process, which might not be helpful >> here. Do not know if it can be turned off. When Proguard is run against >> an Android app, some optimizations are disabled, but not that one. >> >> [proguard] Ignoring unused library classes... >> [proguard] Original number of library classes: 19088 >> [proguard] Final number of library classes: 1048 >> [proguard] Printing kept classes, fields, and methods... >> ** Removed ** >> [proguard] Shrinking... >> [proguard] Removing unused program classes and class elements... >> [proguard] Original number of program classes: 1219 >> [proguard] Final number of program classes: 910 >> [proguard] Inlining subroutines... >> [proguard] Optimizing... >> [proguard] Number of finalized classes: 462 >> [proguard] Number of vertically merged classes: 8 >> [proguard] Number of horizontally merged classes: 27 >> [proguard] Number of removed write-only fields: 221 >> [proguard] Number of privatized fields: 1467 >> [proguard] Number of inlined constant fields: 58 >> [proguard] Number of privatized methods: 773 >> [proguard] Number of staticized methods: 199 >> [proguard] Number of finalized methods: 6007 >> [proguard] Number of removed method parameters: 281 >> [proguard] Number of inlined constant parameters: 233 >> [proguard] Number of inlined constant return values: 50 >> [proguard] Number of inlined short method calls: 2348 >> [proguard] Number of inlined unique method calls: 1573 >> [proguard] Number of inlined tail recursion calls: 22 >> [proguard] Number of merged code blocks: 138 >> [proguard] Number of variable peephole optimizations: 8986 >> [proguard] Number of arithmetic peephole optimizations: 258 >> [proguard] Number of cast peephole optimizations: 251 >> [proguard] Number of field peephole optimizations: 49 >> [proguard] Number of branch peephole optimizations: 3766 >> [proguard] Number of string peephole optimizations: 1148 >> [proguard] Number of simplified instructions: 943 >> [proguard] Number of removed instructions: 6557 >> [proguard] Number of removed local variables: 1196 >> [proguard] Number of removed exception blocks: 470 >> [proguard] Number of optimized local variable frames: 3028 >> [proguard] Shrinking... >> [proguard] Removing unused program classes and class elements... >> [proguard] Original number of program classes: 910 >> [proguard] Final number of program classes: 869 >> >> >> Jeff Palmer >> WhatIf Squared LLC >> >> On Dec 6, 2012, at 8:53 PM, xml...@li...wrote: >> >> *From: *Arno Puder <ar...@pu...> >> *Subject: **Re: [xmlvm-users] One small XMLVM benchmark* >> *Date: *December 6, 2012 8:55:46 PM EST >> *To: *Steve Hannah <st...@we...> >> *Cc: *"xml...@li..." < >> xml...@li...> >> >> >> >> well, allow me some remarks. As you already alluded to, performance >> testing is a tricky business. XMLVM cross-compiles to C code and by its >> very nature it cannot do hot-patching at runtime. This means that every >> static access to a class needs to check if that class was already >> initialized. If your application is mainly using static fields and methods >> (as did your original test case), XMLVM can't do many optimizations. >> >> XMLVM is far from being perfect, but it is doing a decent job. Mileage >> may vary depending on the details of an app. It is always a good idea to >> try different tools and pick the one that works best for you. >> >> Arno >> >> >> > > -- > Steve Hannah > Web Lite Solutions Corp. > > -- Steve Hannah Web Lite Solutions Corp. |
