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

Memoize/cache local evals (package list generation) #381

Open
Atemu opened this issue Dec 20, 2023 · 1 comment
Open

Memoize/cache local evals (package list generation) #381

Atemu opened this issue Dec 20, 2023 · 1 comment

Comments

@Atemu
Copy link
Contributor

Atemu commented Dec 20, 2023

Local evals take quite a long time, about 2 minutes on my rather fast machine. Often times however, you will have already eval'd some revision before. For example, running two reviews against master after another. Because master is unchanged, it will result in the same eval. If eval was cached/memoized, the local eval time would be halved.

I tried implementing this using joblib.Memory but ran into some roadblocks:

  1. No static access cache dir (i.e. ~/.cache/nixpkgs-review/)
  2. list_packages() takes the nix_path as argument which contains a random file name with the generated overlay which makes it impossible to memoize function args
  3. Unclear what revision we're evaluating when list_packages() is called

To fix #2 we should perhaps look into moving the overlay out of the eval step; allowing everything during package list generation (static .nix file!) and filtering later when figuring out what to build.

Ideally, we could also incorporate ofBorg evals here. For that to happen, we would need ofBorg to produce before and after lists that we could turn into list[Package] but that shouldn't be too hard?

@Mic92
Copy link
Owner

Mic92 commented Jan 4, 2024

Some cache that does dict[commit, list[Packages]] might work. The results could be stored as json. Also using ofborg seems like a good idea.

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

No branches or pull requests

2 participants