Investigate Proguard for additional backend optimiztion

[bixuanzju]

http://proguard.sourceforge.net/

[tomtau]

I made an artificial example:

type Doc[A] = {
  concat : A -> A -> A,
  nil    : A,
  text   : String -> A
};
let printAlg: Doc[String] = {
  concat = \(x: String) (y: String) -> x.concat(y),
  nil    = "",
  text   = \(x: String) -> x
};
let parens [A] (f: Doc[A]) (doc: A) = f.concat (f.concat (f.text "(") doc) (f.text ")");
let hello [A] (f: Doc[A]) = f.concat (f.text "Hello") (f.text ", world!");
let random = new java.util.Random( );
let veryBig = new java.math.BigInteger(3500, random);
{veryBig.nextProbablePrime();
        parens [String] printAlg (hello [String] printAlg) }

It's the pretty printer example with extra long running method calls (and its value isn't used). ProGuard has some optimizations for removing method calls (from JDK classes) without side-effects if their values aren't used.

$ time java -jar pretty.jar 
(Hello, world!)

real    1m4.217s
user    1m5.985s
sys 0m0.199s

$ time java -jar pretty-opt.jar 
(Hello, world!)

real    0m24.420s
user    0m26.119s
sys 0m0.160s

But it's an artificial example -- it'll be interesting to use ProGuard on some larger code that was written in SF -- I guess some of the parser combinators?