Memoize the name lookups of JavaParserUtil.resolveTypeName - #8182
Conversation
Resolving one type name looks up many candidate names -- one per enclosing type declaration, one per import, one per on-demand import, one in the same package, one in `java.lang`, and one for the name as a fully-qualified name. Most of those names name no type, and a client that resolves many names looks up the same names over and over. Add an overload of `resolveTypeName` that takes a cache, and route every lookup through it, so that a client that resolves many names pays for each distinct name only once. The cache records a lookup that finds no type, which is the common case. The existing one-argument overload is unchanged from a caller's point of view; it allocates a cache that lives for the one call. This is a performance change; it does not change any result. A cache must not be reused across annotation processing rounds or across `Elements` instances, because a name that names no type in one round might name a generated type in a later round; the Javadoc says so. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: ASSERTIVE Plan: Advanced Run ID: 📒 Files selected for processing (1)
Included review availability: Your plan provides up to 4 included reviews per hour; 2 remain after this review. 📝 WalkthroughWalkthrough
Priority: ⬇️ Low Change: Refactor Merge Risk: ⚪ Minimal · up to The memoization change retains the existing resolver behavior while documenting safe cache scope. No actionable merge risk remains. 🚥 Pre-merge checks | ✅ 3✅ Passed checks (3 passed)
✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
2 participants
Resolving one type name looks up many candidate names -- one per enclosing type declaration, one per import, one per on-demand import, one in the same package, one in
java.lang, and one for the name as a fully-qualified name. Most of those names name no type, and a client that resolves many names looks up the same names repeatedly.Add an overload of
resolveTypeNamethat takes a cache, and route every lookup through it. The existing one-argument overload is unchanged from a caller's point of view; it allocates a cache that lives for the one call.This is a performance change only: it changes no result, and no test output changes. A cache must not be reused across annotation processing rounds or across
Elementsinstances, because a name that names no type in one round might name a generated type in a later round; the Javadoc says so.🤖 Generated with Claude Code