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

Associate deps cache files with the depended upon module #6263

Merged
merged 23 commits into from
Jan 31, 2019
Merged

Conversation

msullivan
Copy link
Collaborator

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.)

Copy link
Collaborator

@JukkaL JukkaL left a 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.

mypy/build.py Outdated Show resolved Hide resolved
mypy/build.py Outdated Show resolved Hide resolved
mypy/build.py Outdated Show resolved Hide resolved
mypy/build.py Outdated Show resolved Hide resolved
mypy/build.py Outdated Show resolved Hide resolved
mypy/build.py Show resolved Hide resolved
mypy/build.py Outdated Show resolved Hide resolved
mypy/server/update.py Show resolved Hide resolved
mypy/test/testfinegrained.py Outdated Show resolved Hide resolved
Copy link
Collaborator

@JukkaL JukkaL left a 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 Show resolved Hide resolved
mypy/build.py Show resolved Hide resolved
mypy/build.py Show resolved Hide resolved
mypy/build.py Outdated
fg_deps_meta = manager.fg_deps_meta.copy()

for id in rdeps:
if id != '@root':
Copy link
Collaborator

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'?

mypy/build.py Outdated Show resolved Hide resolved
mypy/build.py Outdated Show resolved Hide resolved
mypy/build.py Show resolved Hide resolved
mypy/build.py Outdated Show resolved Hide resolved
@msullivan msullivan merged commit 4be41e4 into master Jan 31, 2019
@msullivan msullivan deleted the invert-deps branch January 31, 2019 18:55
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants