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

Slow fingerprinting #4439

Open
ansman opened this issue Sep 15, 2024 · 1 comment
Open

Slow fingerprinting #4439

ansman opened this issue Sep 15, 2024 · 1 comment

Comments

@ansman
Copy link

ansman commented Sep 15, 2024

We're seeing very long fingerprinting times in some hilt tasks.

Our app module's hiltJavaCompileDebug and hiltJavaCompileDebugUnitTest spends over 1 minute to fingerprint inputs on CI, only to determine it's up to date. This is by far the longest tasks in our project.

It's possible this is unavoidable but if possible this should be reduced.

Gradle: 8.10
Dagger: 2.52
Java: 21
AGP: 8.6.0
Module count: 482

@danysantiago
Copy link
Member

danysantiago commented Sep 25, 2024

We expect the fingerprinting of inputs to be decently large for hiltJavaCompileDebug but over a minutes does sound large for something that is meant to prevent the task from executing. The inputs are possibly very large, they are essentially all of your app's runtime classpath, i.e. all of those 482 modules and their transitive dependencies.

This is by design since Hilt perform modules and entry points aggregations at the root (the app), and then creates a big @Component for Dagger. Then Dagger's ComponentProcessor and its superficial validator visit every class that is reachable from the created @Component class, including class referenced in public APIs.

I do believe it is likely including too many dependencies, clearly a 2nd level transitive dependency of a third-party library will not be reachable from Dagger, the challenge for us will be figuring out how we can reduce the inputs.

One workaround you can try is to disable the aggregation (via enableAggregatingTask = false in the Hilt Plugin) and manually include every dependency that Dagger will need at the app's module. Most of the time if there is a missing dependency there will be a compilation error, but the dangerous part is modules with multibindings, a missing dependency might mean a missing multibinding value and that can be hard to diagnose and track. This approach is not great but is what we should strive to aim for with the aggregation, to be as equivalent as if the project was correctly configured in terms of api and implementation dependencies for Dagger.

I'll try to raise this with the team and come back if we end up with a plan. Let me know if you have more questions.

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