-
-
Notifications
You must be signed in to change notification settings - Fork 2.9k
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
Associate deps cache files with the depended upon module #6263
Conversation
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.
Great, this should make daemon cold build using remote cache significantly faster. It also looks like this can save a good chunk of memory, which is a nice bonus.
Did a quick pass and mostly left questions and requests for clarification. I'll do a more detailed pass tomorrow.
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.
Thanks for the updates! The code is now much easier to understand. This is a great approach to speed up daemon startup. Left a few additional minor comments.
mypy/build.py
Outdated
fg_deps_meta = manager.fg_deps_meta.copy() | ||
|
||
for id in rdeps: | ||
if id != '@root': |
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.
What about using a constant for '@root'
?
Currently the fine-grained deps cache file for a module contains all the
fine-grained dependencies from the module (that is, those whose
targets are in the module). This has the advantage that producing fine-grained
dependency cache files is nicely localized (just run it on a module), but
the downside that loading the fine-grained deps cache is a global operation,
requiring every cache file to be loaded.
To improve daemon performance, we invert this, and have the deps cache file
for a module contain the fine-grained dependencies to the module. This
complicates creating the cache files: we need to explicitly sort out triggers
into the appropriate cache file.
This, then, allows us to postpone loading deps cache files until the module
is updated.
Because protocol dependencies now get sorted out into modules like everything
else, this notionally eliminates the special protocol deps cache. In practice, the
protocol deps cache has morphed in a cache for 'extra' dependencies that weren't
placed somewhere else (either because the module doesn't exist or because they
were added in an incremental run) and the meta file for it has grown additional
metadata to check consistency of the deps cache. (Because deps files are now
written after metadata, we can't store info about the in the metadata files.)