-
Notifications
You must be signed in to change notification settings - Fork 1.4k
[PackageLoading] Use a simpler manifest cache #2840
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
Conversation
@swift-ci smoke test |
Thanks for this simplification — I think it's great to reduce the complexity here! I don't see any aging of entries from the database, though — what's the strategy for preventing unbounded growth? |
I am considering cache eviction orthogonal since we don’t have that today either but it should be easy to do something since we now have full control over the cache. |
@swift-ci smoke test self hosted |
0b39c8b
to
c528c32
Compare
@swift-ci smoke test self hosted |
@swift-ci smoke test |
This switches the manifest cache approach used inside manifest loader to directly use sqlite database instead of going through llbuild. The main reason for this switch is to simplify caching behavior and take advantage of SQLite's WAL mode for concurrent access. A separate PR will make the manifest cache global for the user.
@swift-ci smoke test |
This reverts commit 13d60ca.
This reverts commit 13d60ca.
This switches the manifest cache approach used inside manifest loader to
directly use sqlite database instead of going through llbuild. The main
reason for this switch is to simplify caching behavior and take
advantage of SQLite's WAL mode for concurrent access. A separate PR will
make the manifest cache global for the user.