Latest Results
Initialize the workspace cache before spawning the main thread (#20989)
Linux users can encounter tens of milliseconds of avoidable startup
latency when `uv` initializes `WorkspaceCache` after spawning its
`main2` thread, even when dependency caches are warm.
`WorkspaceCache::default()` constructs an
[`uv_once_map::OnceMap`](https://github.com/astral-sh/uv/blob/f60ba1f0c5dd216f7517170f7fe2543b3e512fcd/crates/uv-once-map/src/lib.rs#L147-L153),
which builds a
[`papaya::HashMap`](https://github.com/ibraheemdev/papaya/blob/v0.2.4/src/map.rs#L224-L233)
and initializes a
[`seize::Collector`](https://github.com/ibraheemdev/seize/blob/v0.5.1/src/collector.rs#L29-L37).
On Linux, the collector [registers
`MEMBARRIER_CMD_REGISTER_PRIVATE_EXPEDITED`](https://github.com/ibraheemdev/seize/blob/v0.5.1/src/raw/membarrier.rs#L183-L198)
so concurrent readers can use lighter-weight memory barriers.
[RCU (read-copy-update)](https://docs.kernel.org/RCU/whatisRCU.html) is
a Linux kernel synchronization mechanism that lets existing readers
finish before shared state is safely updated or reclaimed; the time
spent waiting for those readers is an RCU grace period. The kernel's
[`membarrier` registration
code](https://github.com/torvalds/linux/blob/v7.0/kernel/sched/membarrier.c#L438-L466)
has an inexpensive fast path when the process has only one address-space
user (`mm_users == 1`). Once `main2` exists, it instead calls
`synchronize_rcu()` and waits for a grace period before updating
scheduler state. [The kernel documentation
explains](https://docs.kernel.org/RCU/Design/Requirements/Requirements.html)
that these waits favor throughput over latency and can add several
milliseconds.
Construct `WorkspaceCache` before spawning `main2`, while the process
can still use the kernel's single-threaded fast path, and pass the same
cache into command execution. This preserves the existing `uv::run`
entry point and `papaya`'s concurrent behavior.
On Namespace runners, warm, offline `uv workspace metadata --sync
--script` invocations of the original Prefect scripts improved as
follows. Each result is the median of 15 interleaved samples, reported
as before → after:
| Runner | `all_links_should_be_ok.py` | `wait-for-server.py` |
| -------------- | --------------------------- |
------------------------ |
| Linux, 1 CPU¹ | 49.6 → 30.9 ms (−37.6%) | 344.8 → 329.6 ms (−4.4%) |
| Linux, 2 CPUs¹ | 44.4 → 28.5 ms (−35.7%) | 279.7 → 262.2 ms (−6.3%) |
| Linux, 4 CPUs | 40.9 → 27.3 ms (−33.2%) | 252.0 → 236.4 ms (−6.2%) |
| Linux, 8 CPUs | 47.8 → 24.6 ms (−48.5%) | 247.2 → 225.1 ms (−8.9%) |
| Linux, 16 CPUs | 48.5 → 24.2 ms (−50.1%) | 249.2 → 231.9 ms (−7.0%) |
| macOS, 12 CPUs | 19.9 → 19.9 ms (+0.4%) | 215.2 → 218.1 ms (+1.4%) |
¹ CPU affinity on the four-core Namespace runner. [Benchmark workflow
run](https://github.com/astral-sh/uv-dev/actions/runs/31107699452).
---------
Co-authored-by: zaniebot <242828183+zaniebot@users.noreply.github.com>
Co-authored-by: Zanie Blue <contact@zanie.dev> Latest Branches
0%
0%
zaniebot:zb/workspace-metadata-quiet-output 0%
zb/workspace-metadata-stream-json © 2026 CodSpeed Technology