You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
For saving the per-project cache, we should guarantee that after RAR is done, the cache contains exactly the data needed for this specific project. This would be done by keeping track of the items used during RAR execution, and writing those and only those to the cache. Having a cache that's guaranteed to have certain well-defined content after each build is a very good property to have. For instance, in dev box scenarios it would otherwise be hard to reliably "prime" a repo enlistment - the system may prime by building the full solution and then the developer uses the box to build a specific project that happens to have an incomplete cache and get sub-optimal first-time build performance.
Saving of the per-project disk cache may be further optimized by
Keeping the timestamp of the cache file in memory and skipping the save if the relevant cache items haven't become dirty (i.e. the dependencies have not changed) and the timestamp of the cache file hasn't changed since the last save. In hot inner loop scenarios this would reduce the save to a timestamp check.
Saving the file asynchronously, i.e. not blocking the build on completing the save operation.
The text was updated successfully, but these errors were encountered:
This issue tracks implementing the optimization per https://github.com/dotnet/msbuild/blob/main/documentation/design/rar-core-scenarios.md#save-only-relevant-data-to-the-per-project-disk-cache
Parent user story: #8422
For saving the per-project cache, we should guarantee that after RAR is done, the cache contains exactly the data needed for this specific project. This would be done by keeping track of the items used during RAR execution, and writing those and only those to the cache. Having a cache that's guaranteed to have certain well-defined content after each build is a very good property to have. For instance, in dev box scenarios it would otherwise be hard to reliably "prime" a repo enlistment - the system may prime by building the full solution and then the developer uses the box to build a specific project that happens to have an incomplete cache and get sub-optimal first-time build performance.
Saving of the per-project disk cache may be further optimized by
The text was updated successfully, but these errors were encountered: