Summary
A command can build the workspace discovery cache twice even when settings resolution leaves the cache root unchanged.
The early discovery performed while resolving settings populates a WorkspaceCache. run() then creates a new default WorkspaceCache before command dispatch, so the same large workspace is discovered again.
This appears to be a remaining in-process cache reuse opportunity after #12096 and the large-workspace startup work in #18311.
Reproduction
I used an offline synthetic workspace with 1,500 members and measured a release build with two independent runs of 30 alternating baseline/candidate pairs.
Current main:
- workspace discovery builds: 2
- mean startup time: 185.775 ms
- median startup time: 184.607 ms
A small prototype reuses the early cache only when the provisional and resolved cache roots are equal:
- workspace discovery builds: 1
- mean startup time: 124.233 ms
- median startup time: 120.863 ms
- mean reduction: 33.13%
- faster in 59 of 60 paired samples
When uv.toml changes the cache root, the prototype creates a fresh cache and discovery remains 2 to 2.
Proposed scope
- carry the early WorkspaceCache into command dispatch
- reuse it only when the resolved cache root matches
- retain existing invalidation behavior for workspace mutation paths
- add a focused regression test for matching and changed cache roots
The prototype passes the focused regression, uv-workspace tests, workspace integration tests, cargo check, clippy, fmt, and diff checks.
Would this small follow-up be welcome as a pull request?
Summary
A command can build the workspace discovery cache twice even when settings resolution leaves the cache root unchanged.
The early discovery performed while resolving settings populates a WorkspaceCache. run() then creates a new default WorkspaceCache before command dispatch, so the same large workspace is discovered again.
This appears to be a remaining in-process cache reuse opportunity after #12096 and the large-workspace startup work in #18311.
Reproduction
I used an offline synthetic workspace with 1,500 members and measured a release build with two independent runs of 30 alternating baseline/candidate pairs.
Current main:
A small prototype reuses the early cache only when the provisional and resolved cache roots are equal:
When uv.toml changes the cache root, the prototype creates a fresh cache and discovery remains 2 to 2.
Proposed scope
The prototype passes the focused regression, uv-workspace tests, workspace integration tests, cargo check, clippy, fmt, and diff checks.
Would this small follow-up be welcome as a pull request?