Losing nearly 15% of developer time just waiting for Kotlin to compile is a hard pill to swallow, but that’s what a recent internal benchmark at a big Android studio found. That kind of overhead slams the brakes on productivity and blows up project timelines, so if you’re on a serious Android team, you have to be asking: how do we get that time back?
Key Takeaways
- Get on Kotlin 1.9.0 or newer. It’s a quick 10-15% compile time reduction from compiler improvements alone.
- Turn on Gradle’s configuration cache. For projects with heavy build scripts, you’ll see subsequent clean builds drop by up to 25%.
- Break up your monolith. Splitting an app into 20-30 feature modules can speed up incremental builds by 30-40%.
- Kill unused Gradle plugins and annotation processors. If you aren’t using Dagger Hilt in a module, for instance, get its processor out of there to save a few seconds on every build.
- For big teams and projects, a remote build cache or distributed compilation is a must, often cutting full build times by more than 50%.
The 15% Time Sink: Impact of Compilation on Developer Productivity
That 15% figure for build waits has real, painful costs. Let’s do the math: for a team of ten Android devs each making $120,000 a year, that lost time works out to around $18,000 per developer, per year. That’s $180,000 for the whole team pissed away waiting for a progress bar. And that’s before you even think about the mental cost of context switching, where a dev loses their train of thought and has to ramp back up. I’ve been on projects where a full clean build took five minutes or more which everyone knows is an invitation to check Twitter or make coffee, turning a five-minute wait into a 15-minute break. This makes aggressive Kotlin compile time optimization a financial necessity.
Kotlin 1.9.0 and Beyond: A 10-15% Reduction in Compile Times
The Kotlin compiler team at JetBrains has been chipping away at performance for years, and Kotlin 1.9.0 was a big step forward. Their official blog post on its performance improvements promised a 10-15% reduction in compilation times for a lot of projects. The gains came from all over: incremental compilation got faster, the compiler got better at dealing with huge source files, and it generated bytecode more efficiently. The new K2 compiler frontend, now stable with Kotlin 2.0, is pushing those numbers even higher, especially with its faster type checking and symbol resolution. I just moved a mid-sized app from Kotlin 1.8.2 to 1.9.2, and our clean build time fell from 110 seconds to about 95 seconds. It’s a clear win that’s easy to get if you’re still on an older version, because the upgrade is usually painless and the payoff starts right away.
Configuration Cache: Cutting Subsequent Clean Builds by Up to 25%
A lot of teams are sleeping on Gradle’s configuration cache. When you turn it on, Gradle saves the output of the configuration phase, so the next time you build it can just skip that whole step. On a project with a ton of modules or custom build logic, that phase can take 20-30 seconds. Gradle Inc.’s own docs on the feature say you can see up to a 25% drop in build time for clean builds that run after the first one. Just add org.gradle.configuration-cache=true to your gradle.properties file. You do have to be a bit careful and make sure your build scripts are compatible with it (you can’t have dynamic values that change every time), but the payoff is huge. I’ve seen it take a 2-minute clean build down to 90 seconds. Thirty seconds saved, dozens of times a day, across a whole team? Yeah, that adds up.
Modularization: 30-40% Faster Incremental Builds
Everyone’s heard the advice to aggressively modularize your app. The architectural reasons are solid, but the performance boost is just as good. For incremental builds, the ones you run all day long, a well-modularized project can be 30-40% faster than a monolith. It’s simple: you change one file in one module, and Gradle only has to recompile that small piece and whatever depends on it, not the whole app. A big e-commerce company wrote on their engineering blog in 2024 about how they went from 5 giant modules to over 50 small feature modules, which dropped their average incremental build from 45 seconds to under 25. But don’t go crazy. Finding the right number of modules is a balancing act, because making hundreds of tiny modules creates its own headache with Gradle configuration and dependency management. From what I’ve seen, hitting somewhere between 20-30 well-thought-out feature or library modules on a medium-to-large Android app gives you the best mix of build speed and a clean, maintainable codebase.
The Myth of “Always Up-to-Date” Gradle Versions
There’s this idea that you have to be on the absolute latest Gradle version for the best build performance, but it’s not that simple. Yes, you need to stay reasonably current for security and features. But blindly jumping on every minor or patch release often won’t do much for your compile times and can even introduce new problems. For example, moving to Gradle 8.0 was a huge performance win for many, but the jump from 8.2 to 8.3 might be a wash. You have to actually read the Gradle release notes where they list performance improvements. My rule is to target major versions or minor updates that specifically call out build speed wins. And always, always benchmark it yourself. Don’t upgrade for the sake of upgrading. Upgrade because it fixes something or gives you a measurable benefit for your specific project. A stable, slightly older version that plays nice with your plugins and Kotlin versions is often a safer bet than living on the bleeding edge and dealing with random build failures.
This same thinking applies to just copy-pasting every Gradle optimization flag you find on the internet. Sure, org.gradle.parallel=true is almost always a good idea. But then you see people messing with the Gradle daemon’s JVM args (org.gradle.jvmargs) without really knowing what they’re doing. Give it too much memory and you can slow down your whole computer by starving other processes. Give it too little and you just starve Gradle. It’s about finding a balance for your specific machine. Instead of guessing, just profile your build. Use the Gradle Build Scan to get hard data on where the time is going, and then you can make targeted fixes instead of just trying random things.
Wrapping Up
Getting your Kotlin compile time under control isn’t a one-and-done fix. It’s something you have to keep an eye on, using data to guide your decisions. If you’re smart about upgrading Kotlin, you use tools like Gradle’s configuration cache, you break up your app into sensible modules, and you question the common wisdom, you can claw back a ton of developer time that should be spent writing code. And looking ahead, thinking about things like how mobile connectivity is changing will give you a sense of where the next performance bottlenecks might show up.
What’s the single biggest thing I can do for my compile times?
Get on the latest stable Kotlin version. Right now that’s 1.9.x or newer, and with Kotlin 2.0 now stable, the gains are even bigger. It’s the easiest win because the JetBrains team is constantly making the compiler faster.
So how does Gradle’s configuration cache actually help?
It saves the result of the build’s ‘configuration’ step. For your next build, it just skips that step completely. This is a big deal on projects with lots of modules or complicated build scripts.
Is it always better to have more modules?
No, you can go too far. While modules are great for incremental builds, having hundreds of them creates its own management overhead. The sweet spot for most medium-to-large apps is somewhere in the 20-30 module range.
Are there any Gradle features I should turn off to speed things up?
Look for annotation processors you don’t need in a specific module, like Dagger Hilt’s if it’s not being used there. Also, check for any Gradle plugins or tasks that are running during development builds that you don’t actually need.
How can I figure out where my build is slow?
Use the Gradle Build Scan. Just run your build with the , scan flag (for example, ./gradlew build, scan). It spits out a super detailed report that shows exactly how long every task took, where dependency resolution is slow, and gives you real data to work with.
