Flake evaluation cache #2930
Flake evaluation cache #2930
Conversation
This exploits the hermetic nature of flake evaluation to speed up
repeated evaluations of a flake output attribute.
For example (doing 'nix build' on an already present package):
$ time nix build nixpkgs:firefox
real 0m1.497s
user 0m1.160s
sys 0m0.139s
$ time nix build nixpkgs:firefox
real 0m0.052s
user 0m0.038s
sys 0m0.007s
The cache is ~/.cache/nix/eval-cache-v1.sqlite, which has entries like
INSERT INTO Attributes VALUES(
X'92a907d4efe933af2a46959b082cdff176aa5bfeb47a98fabd234809a67ab195',
'packages.firefox',
1,
'/nix/store/pbalzf8x19hckr8cwdv62rd6g0lqgc38-firefox-67.0.drv /nix/store/g6q0gx0v6xvdnizp8lrcw7c4gdkzana0-firefox-67.0 out');
where the hash 92a9... is a fingerprint over the flake store path and
the contents of the lockfile. Because flakes are evaluated in pure
mode, this uniquely identifies the evaluation result.
| SQLite(const SQLite & from) = delete; | ||
| SQLite& operator = (const SQLite & from) = delete; | ||
| SQLite& operator = (SQLite && from) { db = from.db; from.db = 0; return *this; } | ||
| ~SQLite(); | ||
| operator sqlite3 * () { return db; } | ||
|
|
||
| /* Disable synchronous mode, set truncate journal mode. */ | ||
| void isCache(); |
There was a problem hiding this comment.
Just came across this in the source code. isCache really doesn't speak well for what it is doing. Maybe just calling it setTruncateJournalMode would have been better?
There was a problem hiding this comment.
No, that's an implementation detail. "isCache" is a more declarative statement - i.e. "this database is a cache so do whatever is possible to make it fast at the expensive of reliability".
There was a problem hiding this comment.
At first glance I would agree that setTruncateJournalMode seems to expose an implementation details and is thus maybe not ideal (On the other hand you added a comment saying "Disable synchronous mode, set truncate journal mode" because it would be very hard to derive that otherwise i guess)
From my point of view isCache is equally bad: My expectation is that any function adhering to a isSomething naming scheme falls into the category of predicate functions:
if (Something is satisfied) return true else return false
But isCache returns void and does some stuff that you cannot guess without reading the comment so i am not sure this is in fact very "declarative".
It's not entirely clear to me what the level of abstraction is here, and if isCache is part of some API or if it is only ever going to exist for SQLite.
- If this will only ever exist in the context of SQLite then this is implementation specific already and then i'm not sure why this shouldn't actually say what it does.
- if this is something that different storage classes will implement then I think a name like
useAsCachewould be more appropriate.
WDYT?
This exploits the hermetic nature of flake evaluation to speed up repeated evaluations of a flake output attribute.
For example (doing
nix buildon an already present package):The cache is
~/.cache/nix/eval-cache-v1.sqlite, which has entries likewhere the hash
92a9...is a fingerprint over the flake store path and the contents of the lockfile. Because flakes are evaluated in pure mode, this uniquely identifies the evaluation result.