Skip to main content

Module store

Module store 

Source
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.