Or does it? Facebook developers have just described a project that aims to optimize Java byte code. The post is impressive. but it gives the impression that it is breaking new ground - it isn't.

You tend to think of optimizations such as minification as being relevant only to interpreted languages such as JavaScript and not at all suitable for compiled code such as byte code. This, however, ignores that fact that byte code isn't as low level as you might think. Byte code includes the names of variables and other symbols and complete paths to where things are stored. After all byte code is designed to be interpreted by the JVM and as such is contains a lot of information that would be missing from a machine code program reduced to machine operations and addresses. 

Facebook has a implemented an optimizer that works directly with the DEX code destined for the Android Dalvik interpreter.

It performs a number of stages of optimization including:

Minification and compression

It replaces human readable strings in the byte code by small unique generated identifiers.  

inlining

If a function calls another function then it is more efficient to convert the call into inline code by putting the code of the called function in the calling function.

Removing unused wrapper functions

Remove set/get functions that aren't used.

Dead code elmimination

Walk the function graph and remove any code that is unreachable. 

Of course, making all of this work properly so that it makes the DEX code smaller without introducing subtle bugs is difficult. The blog post ends with a promise for more information on additional optimizations. 

However, there are other byte code optimizers and in fact Android Studio ships with, and makes use of, Proguard, an open source byte code obfuscator and optimizer. Using it is just a matter of targeting a final release version. Proguard seems to do everything that Redex does - dead code removal etc. The list provided by the Proguard website seems to cover just about everything that Redex does and more: 

• Evaluate constant expressions.
• Remove unnecessary field accesses and method calls.
• Remove unnecessary branches.
• Remove unnecessary comparisons and instanceof tests.
• Remove unused code blocks.
• Merge identical code blocks.
• Reduce variable allocation.
• Remove write-only fields and unused method parameters.
• Inline constant fields, method parameters, and return values.
• Inline methods that are short or only called once.
• Simplify tail recursion calls.
• Merge classes and interfaces.
• Make methods private, static, and final when possible.
• Make classes static and final when possible.
• Replace interfaces that have single implementations.
• Perform over 200 peephole optimizations, like replacing ...*2 by ...<<1.
• Optionally remove logging code.

This raises the question of how good Redex is compared to Proguard, something not covered in the Facebook post.

It also makes you wonder why the Facebook team didn't start by forking Proguard if they wanted to do better? The only big difference is that Proguard works on the byte code, and hence works with all versions of Java, and Redex works with the DEX byte code and hence only works with Android. However there is a commercial version of Proguard that does work with DEX files.

Facebook has been nice to the programmer community by releasing open source code for various tools. In this case there is no word on when or if Redex will be made available. If it ever is then it certainly won't be entering a vacuum.

Comments

Make a Comment or View Existing Comments Using Disqus

or email your comment to: comments@i-programmer.info