fb/proguard seems worse than vanilla

[facebookarchive]

fb/proguard seems worse than vanilla

[alsutton]

We use it on our internal apps and we've seen the opposite. Can you share the code you ran your tests on?

[kageiit]

You can run the example that ships with proguard itself

Fb Fork

time java -jar lib/proguard.jar @examples/proguard.pro
ProGuard, version 5.3.1
Reading program jar [/Users/kage/src/proguard/lib/proguard.jar] (filtered)
Reading library jar [/Library/Java/JavaVirtualMachines/jdk1.8.0_112.jdk/Contents/Home/jre/lib/rt.jar]
Preparing output jar [/Users/kage/src/proguard/examples/proguard_out.jar]
  Copying resources from program jar [/Users/kage/src/proguard/lib/proguard.jar] (filtered)

real    0m8.511s
user    0m23.466s
sys 0m0.603s

Vanilla 5.3.1

time java -jar lib/proguard.jar @examples/proguard.pro
ProGuard, version 5.3.1
Reading program jar [/Users/kage/src/proguard-code/lib/proguard.jar] (filtered)
Reading library jar [/Library/Java/JavaVirtualMachines/jdk1.8.0_112.jdk/Contents/Home/jre/lib/rt.jar]
Preparing output jar [/Users/kage/src/proguard-code/examples/proguard_out.jar]
  Copying resources from program jar [/Users/kage/src/proguard-code/lib/proguard.jar] (filtered)

real    0m8.224s
user    0m23.356s
sys 0m0.633s

[kageiit]

I also ran a test on this opensource project
https://github.com/uber/okbuck

command to run
./buckw build another-appRelease

and then switched out the custom proguard jar from tools/proguard.jar to vanilla 5.3.1 and this fork after to check the results. I then looked at the buck build trace files

Vanilla 5.3.1

This fork

[kageiit]

I think you should test vanilla proguard 5.3.1 on your internal apps to check if this fork is still useful to maintain

[alsutton]

I'm still seeing some performance gains here, but from your experiments it looks like they may not be universal on all machines types, so I've asked for the "faster" bit to be removed from the description.

Another benchmark you might want to run is memory usage. It's an area we also see improved in the fork, and it should be independent of machine architecture and hardware configuration.

[alsutton]

Just for comparison, here's what I see on my local machine running your test;

Original;

alsutton-mbp:proguard alsutton$ time java -jar lib/proguard.jar @examples/proguard.pro
ProGuard, version 5.3.1
Reading program jar [/Users/alsutton/Projects/proguard/lib/proguard.jar] (filtered)
Reading library jar [/Library/Java/JavaVirtualMachines/jdk1.8.0_91.jdk/Contents/Home/jre/lib/rt.jar]
Preparing output jar [/Users/alsutton/Projects/proguard/examples/proguard_out.jar]
  Copying resources from program jar [/Users/alsutton/Projects/proguard/lib/proguard.jar] (filtered)

real    0m13.505s
user    0m30.435s
sys 0m0.846s

Fork;

alsutton-mbp:fb-proguard alsutton$ rm examples/proguard_out.jar ; time java -jar lib/proguard.jar @examples/proguard.pro
ProGuard, version 5.3.1
Reading program jar [/Users/alsutton/Projects/fb-proguard/lib/proguard.jar] (filtered)
Reading library jar [/Library/Java/JavaVirtualMachines/jdk1.8.0_91.jdk/Contents/Home/jre/lib/rt.jar]
Preparing output jar [/Users/alsutton/Projects/fb-proguard/examples/proguard_out.jar]
  Copying resources from program jar [/Users/alsutton/Projects/fb-proguard/lib/proguard.jar] (filtered)

real    0m13.303s
user    0m30.040s
sys 0m0.782s

[alsutton]

"faster" has been removed from the description.

[kageiit]

what is "different" on your machine exactly? would be nice if we can get those speed benefits if it requires us to tweak our machines somehow

[kageiit]

I am also curious why the changes in the fork cannot be contributed upstream to proguard

[alsutton]

I'm not sure how valuable it'll be digging into hardware and OS components. I'm grateful for you highlighting that you have a configuration where it's not as fast, but I'm not sure a recommended hardware spec for the perf improvements would go down well with many people :).

DexGuard (authors or Proguard) are aware of this fork, but I don't know the reason they have for not taking the patches into the mainstream version.

[alsutton]

After some further internal testing it seems the benefits of the fork become more significant if you're seeing of a lot of GC during a proguard run (usually due to JVM heap size constraints). This is probably down to the string interning patch that we have included.