Redex: an Android bytecode optimizer developed by Facebook

Agreed.

I think the Facebook engineers have a tendency to fix symptoms rather than causes. A lot of their engineering creations are trying to shrink the binary while they might want to consider revisiting all the dependencies that their application depends on, because that graph (and the size of their apk) is really absurdly large for such an app.

Of course, there's also the fact that such a tool is already partially obsolete because of Jack and Jill.

I've actually got to sit down and debug my Nexus 5. I don't run the FB app but it's degrading in the same kind of way. No real easy cause that I can see. I'm hoping adb can shed some light for me.

I'm guessing it has so much old "legacy" code long before all this new cool inventions like React Native etc. were invented.

I wonder why they cannot start from scratch a new one which has a better architecture and does not slow down your phone.

I've never been comfortable with the FB app phoning home so I too use the mobile website. The thing about it is that the text fields don't work well at all. Slow response times, no way to go back and correct my errors without erasing everything, and repetition of words. Over the years and across browsers the issues change but they've never worked like most other text fields on mobile websites. I wish I knew what they were doing to make them behave so poorly.

It is indeed out of control. They have so much stuff in their app that an update takes over 2 minutes to run on Marshmallow on a total high-end device (Snapdragon 810). No other app comes even close to taking that long to precompile for ART.

Which is surprising really, considering their Messenger app is excellent, fast and lean.

Stopped using it and never looked back (as they say). Battery life much improved and more time for other more productive social mediums.

I uninstalled it as well, and noticed that the mobile website for facebook is much better in performance than the so called 'native' app.

Thanks for sharing, do you still see runtime performance benefits when ART is used or just compilation / dex2oat perf improvement?

Does Jack and Jill fuck your shit up?

How are you handling the Gradle experimental plugin and Jack/Jill (no problems because you operate at dex level?)? I heard Proguard and other class/dex transformations were having trouble adopting the new model. Supposedly Google is working on adding extension points to the API.

Can you provide any numbers on the results of these optimisations? They seem to be missing from the website and blog post.

I didn't see any performance numbers in the blogpost. Do you plans to share some benchmarks ?

Yes, of course we do! It's the motivating example for ReDex :-)

Both Proguard and ReDex can be coaxed to unmangle names (produces a special file and has a tool to decode mangled traces)

They don't really do any major optimizations - they're not a real SSA/CSE/eta-form optimizer, like what llvm does to its bytecode.

It's also a well known term in programming language theory: https://www.classes.cs.uchicago.edu/archive/2002/winter/CS33...

It's conceptually similar, but we've focused on optimizations that add value on top of ProGuard - we do use ProGuard internally, so the improvements we're seeing from ReDex are on top of that.

We get a lot of leverage out of operating on dex directly, as the final step in the build. For instance we can make really good inlining decisions because we know how many virtual registers the caller and callee use.

Redex runs at compile time, not at install time.