Expand description
The on-disk store: one file, read whole, written by atomic rename.
§One file, not one per entry
At a couple of thousand files, inode churn dominates: opening, stat-ing and closing a file per cache entry costs more than the work being cached. A single file is one open and one read.
The architecture specifies memory-mapping it. This reads it instead, because the mapping
APIs require unsafe and the workspace denies unsafe_code — trading a lint that holds
everywhere for a performance claim nothing has measured yet would be the wrong way round.
A whole-file read is a single sequential I/O of a few megabytes; if a benchmark ever shows
it on the critical path, that is the moment to revisit both decisions together.
§Nothing here can fail a run
Every operation degrades to “no cache”. A missing file, a corrupt one, an unwritable
directory, a file written by a different build — all mean recompute. This is why the
store’s fallible operations return Option and its write returns (): there is no error
a caller could usefully act on, and one that stopped a run would make the cache a
liability rather than an optimization.
Structs§
- Store
- A loaded cache: what the last run stored, and what this run has produced.