-
Notifications
You must be signed in to change notification settings - Fork 77
chore: cache proto context to optimize generator performance #2531
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
base: main
Are you sure you want to change the base?
Conversation
Summary of ChangesHello @ohmayr, I'm Gemini Code Assist1! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed! This pull request implements a significant performance optimization by introducing a caching mechanism for context-aware schema objects. By passing a shared Highlights
🧠 New Feature in Public Preview: You can now enable Memory to help Gemini Code Assist learn from your team's feedback. This makes future code reviews more consistent and personalized to your project's style. Click here to enable Memory in your admin console. Using Gemini Code AssistThe full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips. Invoking Gemini You can request assistance from Gemini at any point by creating a comment using either
Customization To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a Limitations & Feedback Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here. You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension. Footnotes
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Code Review
This pull request introduces a caching mechanism to optimize with_context calls, which is a good idea for performance. However, the implementation has a few issues that need to be addressed: a critical bug in api.py that will cause a runtime error, and several issues with the caching implementation itself regarding type safety, potential cache corruption, and code duplication. My detailed comments point out these issues with suggestions for fixes.
68e453e to
8e7e903
Compare
ddea9d8 to
58f3049
Compare
cc9e070 to
4965011
Compare
|
|
||
| global_collisions = frozenset(naive.names) | ||
| visited_messages: Set[wrappers.MessageType] = set() | ||
| self.context_cache = {} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why is this state being reset here?
Is the dict passed in at init time used anywhere? This seems to be the only usage?
| """Decorator to memoize with_context calls based on self and collisions.""" | ||
|
|
||
| @functools.wraps(func) | ||
| def wrapper(self, *, collisions, context_cache: Optional[Dict] = None, **kwargs): |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
How does this interact with the visited_messages argument?
I'm having trouble understanding what visited_messages is used for, but this cache doesn't seem to take it into account. Is that ok?
|
|
||
| # 2. Create the cache key | ||
| collisions_key = frozenset(collisions) if collisions else None | ||
| key = (id(self), collisions_key) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
With this key, the cache will only be triggered if both messages have the same memory address, even if the content is identical. Is that the intention? Typically, a hash would be used for this kind of thing. Unless each message is a singleton
a = ("hello",)
b = ("hello",)
>>> id(a), id(b)
(140612776488128, 140612776488000)
>>> hash(a), hash(b)
(2145482566216562249, 2145482566216562249)
| def wrapper(self, *, collisions, context_cache: Optional[Dict] = None, **kwargs): | ||
| # 1. Initialize cache if not provided (handles the root call case) | ||
| if context_cache is None: | ||
| context_cache = {} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Does context_cache need to be optional? It seems to me that the root call creates a new dictionary, if I'm reading it right
Thank you for opening a Pull Request! Before submitting your PR, there are a few things you can do to make sure it goes smoothly:
Fixes #<issue_number_goes_here> 🦕