Android build speed on Apple Silicon

In November last year, Apple revealed their new M1 chip and rolled it out to some models of their Mac lineup. The hype around this release was pretty big and some of the initial benchmarks showed impressive performance improvements compared to older generations. Many Android developers are using MacBooks for their daily work, so we started wondering if the new MacBooks would improve build speed. So we sat down and ran some benchmarks. In this blog post, I want to share the results with you.

A look at the baseline

To get some real-world numbers as a baseline, we measured the runtime of a few Gradle tasks. We used our adidas Running app and measured the duration of

• a clean debug build,
• a clean release build,
• a Lint run (excluding build time) and
• a unit test run (also excluding build time).

Each of these tasks was executed five times, without build cache and with a fresh Gradle daemon. For further comparison, we’re going to use the average of these measurements, even though variance was pretty small (<5s) anyways. The baseline measurements were taken on a 16-inch MacBook Pro from 2019 with an 8-core Intel Core i9 (2.3 GHz) and 16 GB RAM:

Trying the Apple M1

Now that we have a baseline, we can take a look at the Apple M1. Our iOS colleagues lent us a new Mac mini, which we could use for our benchmarks. Since the chip is the same on the MacBooks, the results should be reproducible there (but we didn’t explicitly try it). So we went ahead, set up the environment, and repeated the measurements. However, the results were not quite what we expected:

Judging by the benchmarks we saw, we expected build times to go down or at least stay the same. But instead, they increased by quite some margin. So we did some digging and found the reason for the slower build times.

What makes the Apple M1 somewhat unique is the fact that it’s based on the ARM instruction set, instead of x86 (which is a lot more common on notebooks and desktops). Because of this, existing binaries compiled for x86 do not run natively on the Apple M1. To not break compatibility with existing software, macOS Big Sur contains a translation layer called Rosetta 2. Rosetta 2 automatically kicks in when x86 instructions are executed and translates them into ARM. And while the performance of Rosetta 2 is pretty good, it still adds some overhead compared to native ARM binaries. We initially installed the same JDK as on the MacBook, which happens to be a distribution from AdoptOpenJDK. And since this JDK was targeting x86 instead of ARM, it ran through Rosetta 2 and the performance took quite a hit.

Switching to an ARM JDK

So, we installed a distribution from Zulu OpenJDK instead, which already provided native builds for ARM. This time, repeating the measurements resulted in drastically improved build times, like we had hoped:

Now, this was much closer to some of the other benchmarks we saw. All of the tasks we ran are significantly faster on the Apple M1, some of them even taking less than half of their original time. At first, we had some trouble trusting these results and checked the setup and re-ran the benchmarks multiple times, but the results stayed consistent.

Some caveats

Now before you run out and buy a new MacBook because of these results, let me also share some problems we encountered along the way. Not every tool is compatible out-of-the-box yet. For example, we are using Protobuf, which required a small workaround on ARM. The Android emulator is also not compatible, but there is already a preview version available. Other tools like Gradle work fine through Rosetta 2 (without a noticeable performance hit), but they don’t support Apple silicon natively yet.

We also only looked at a single aspect of the Apple M1. For example, we didn’t check how well Android Studio performs. We also didn’t test how other build systems like Buck or Bazel would behave.

Conclusion

So, is the Apple M1 the holy grail for faster Android build speeds? The numbers look promising and most likely this will even improve over time, as more and more tools get native ARM support. On the other hand, it’s still very early and some issues require workarounds. In the end, as so often, it depends on your individual situation.

I will still wait a bit for a potential second generation, which will hopefully also be available on the 16-inch model. By then, I expect most early-stage problems to be resolved and I hope we all get to enjoy faster build speeds.