Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Significant Build Time Increase with Anvil 2.5.1 #1109

Open
Munzey opened this issue Feb 11, 2025 · 7 comments
Open

Significant Build Time Increase with Anvil 2.5.1 #1109

Munzey opened this issue Feb 11, 2025 · 7 comments

Comments

@Munzey
Copy link

Munzey commented Feb 11, 2025

We have identified a significant increase in build times when upgrading from Anvil 2.5.0 to 2.5.1. Our daily Gradle profiler benchmark run using an abi change scenario running our :app:assembleDebug task shows a 20% increase in build times.

Details:

Project Type: Android app
Kotlin Version: 1.9
Java Version: 17
Anvil Extension Settings:
trackSourceFiles: Enabled/Disabled (no effect)
generateDaggerFactories: true

Scenario:

We apply an ABI change to a base module class that affects multiple downstream modules (e.g., architecture -> feature-core -> feature).
The build is run in an isolated way with all dependencies downloaded, offline mode, no build cache, and no configuration cache.
We run several warm-ups and 10 builds.
Results:

Anvil 2.5.0: Average build time: 26 seconds
Anvil 2.5.1: Average build time: 32 seconds

Additional Observations:

Investigating build scans, all KotlinCompile tasks seem to be marginally slower with Anvil 2.5.1.
With all caching enabled, the same scenario on my local machine resulted in:

Anvil 2.5.0: 18 seconds
Anvil 2.5.1: 27 seconds

We would appreciate any insights or guidance on why this performance regression might be occurring and any potential solutions or workarounds. Hopefully I provided useful information - just wanted to be clear that this benchmark is for a large app (HubSpot) with a non-trivial dependency tree. Thank you for your assistance.

p.s. Hey @JoelWilcox ! its me Tristan 😄

@JoelWilcox
Copy link
Member

Omg hey Tristan! 😁 Thanks for including all the details. A couple questions:

  • Although you're not seeing the numbers affected by the trackSourceFiles flag, can you share if the setting was already turned on prior to upgrading to 2.5.1? Theoretically this shouldn't matter but still worth noting for comparison
  • I noticed that you are using Kotlin 1.9, while Anvil 2.5.1 targets Kotlin 2.0.21. We haven't seen any perf change in the Square apps we use for benchmarking but we also upgraded to Kotlin 2.0.21 first and then to Anvil 2.5.1. Is upgrading Kotlin in your project something that's currently in progress or possible to try out? This would help to further eliminate potential causes for the slowdown

@Munzey
Copy link
Author

Munzey commented Feb 12, 2025

can you share if the setting was already turned on prior to upgrading to 2.5.1

it was already enabled yes, I just tested to see what happens with it set false for both 2.5.0 and 2.5.1 (had little effect on the times)

Is upgrading Kotlin in your project something that's currently in progress or possible to try out?

sorry I should have been more specific with that detail.
We use renovate for auto upgrading versions so our kotlin gradle plugin is in fact on 2.1.10 currently - we just still target api and language version of "1.9" on account of k2

@Munzey
Copy link
Author

Munzey commented Feb 12, 2025

I just tried downgrading the kotlin plugin to 2.0.21 and running the benchmark locally again it still came out with 2.5.0 significantly faster:

Anvil 2.5.0: 24 seconds
Anvil 2.5.1: 35 seconds

@JoelWilcox
Copy link
Member

Okay interesting, so the confusing thing is that effectively the only changes included in the 2.5.1 release were defaulting trackSourceFiles to true and upgrading Anvil to Kotlin 2.0.21, so I'm struggling to think of what else might result in the numbers you're seeing.

Investigating build scans, all KotlinCompile tasks seem to be marginally slower with Anvil 2.5.1

One additional question after rereading ^, does this include compilation of modules that do not use Anvil / apply the Anvil plugin?

@Munzey
Copy link
Author

Munzey commented Feb 14, 2025

One additional question after rereading ^, does this include compilation of modules that do not use Anvil / apply the Anvil plugin?

Good thinking to check that... looks like no obvious effect on KotlinCompile task times on the couple of modules that don't apply anvil.

Sorry I don't know what else to point to 🤔 Thanks for the help investigating so far!
We might just stick to 2.5.0 for now - If I have time I can look to try build a dummy repo to reproduce, though I imagine itll be difficult to replicate given the size/complexity of our project with the specific set up 😕

@Munzey
Copy link
Author

Munzey commented Feb 14, 2025

on a side note - I've only read through the roadmap this week.

Anvil 3.0 sounds exciting! Though we are now debating whether to stick it out or look to adopt zac sweers fork simply to unlock k2.

Any idea of timeline for k2 support? I think that's our bigger concern over whether we want to invest in dagger-ksp or anvil

EDIT: sorry just read this other issue answer 😅

@JoelWilcox
Copy link
Member

Good thinking to check that... looks like no obvious effect on KotlinCompile task times on the couple of modules that don't apply anvil.

Sorry I don't know what else to point to 🤔 Thanks for the help investigating so far!
We might just stick to 2.5.0 for now - If I have time I can look to try build a dummy repo to reproduce, though I imagine itll be difficult to replicate given the size/complexity of our project with the specific set up 😕

Thanks for checking! And no worries, I'm also a bit stumped with what could be causing the issue. If you do end up finding the time to make a reproducer that would be perfect, but also no pressure. It's a lot harder with perf-related issues compared to having a failure scenario.

Anvil 3.0 sounds exciting! Though we are now debating whether to stick it out or look to adopt zac sweers fork simply to unlock k2.

Makes sense! Depending on how many custom code generators you have, migrating to and testing out Zac's fork might not be too big of a lift. I'd be interested to hear how perf numbers end up comparing for you since we weren't able to compare with K2 enabled at the time that we evaluated it internally.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants