Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Store a binding graph's subgraphs as a list instead of a set
BindingGraph.hashCode() is extremely slow as has already been discovered, but even memoizing the value doesn't do much value in cases where it is unlikely for the hash code to be computed and it is only computed once. It should be impossible to try and resolve the same child graph twice for the same graph, and I'd argue that doing so represents a deeper bug in the binding graph resolution algorithm. Not catching the bug will likely result in Dagger attempting to generate the same component implementation twice, in turn causing a compiler error and a better indication of the bug than what we have by keeping a set. We never use this set for set-like properties. We only use it for iteration purposes. This is particularly devastating in ahead-of-time components, where we create N BindingGraph instances for a particular component in a hierarchy, where N is the depth in the hierarchy. Profiling a large component internally with AOT turned on showed BindingGraph.hashCode() taking 7.3s, or 2.8% of the entire compilation (12.4% of total annotation processing). RELNOTES=Peformance improvements in annotation processing ------------- Created by MOE: https://github.com/google/moe MOE_MIGRATED_REVID=225387291
- Loading branch information