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

Improve caching in hint loading #61

Closed
ZacSweers opened this issue Aug 25, 2024 · 1 comment
Closed

Improve caching in hint loading #61

ZacSweers opened this issue Aug 25, 2024 · 1 comment
Labels
enhancement New feature or request

Comments

@ZacSweers
Copy link
Owner

ZacSweers commented Aug 25, 2024

Due to #42, we have to reload hints each round. While perf is much improved with #55, I think we can do more.

  1. ✅ Get back to loading only once from the classpath lazily (i.e. don't load at all until we're for sure generating merged classes). I think we can get back to this by only storing exactly which information is needed, and not keeping symbols.
  2. ✅ Split the populating step out separate from in-round-generated contributions. Similar to what ContributesSubcomponent handling does. Load from the classpath once, load the rest from the Resolver. We would need to introduce a new annotation on generated hint properties to do this to look up with (i.e. @AnvilHint), or possibly consider an alternative that's faster than KSP's lookup of properties.
    • Another option for this could be to wrap everything up in just one processor rather than the current multiple processors. Then the parent processor could ask for the generated types back directly from the delegate processors. That would be a larger scale overhaul though.
  3. Consider reworking hints. This would be a change from upstream, but an optimization we could do would be to limit the scopes we search each time. Currently all hints are generated into a global anvil.hint package. However, we could make the scope part of this package, such that we look in anvil.hint.com.example.appscope for all com.example.AppScope scopes. This lets us more lazily load scopes for various components, though doesn't make much of a difference for projects that merge for all scopes.
  4. ✅ Consider making @ContributesSubcomponent handling another flag that can be opted out of. For projects that don't use it, they can turn this off
@ZacSweers
Copy link
Owner Author

Closing this as resolved for now. We could consider revisiting option 3 in the future if there's a measurable benefit

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

No branches or pull requests

1 participant