Re: [xmlvm-users] One small XMLVM benchmark

[Jeff P. <jcp...@ro...>]

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