2 ms·

Any time you put data onto the file system there is overhead (eg. Memcache, Redis, most databases). Simple things like parsing the bytes into the binary repres

Any time you put data onto the file system there is overhead (eg. Memcache, Redis, most databases). Simple things like parsing the bytes into the binary representation go away. You can have more granularity of the cache because you don't need to worry about creating too many files. Not only from a performance perspective but also from a code perspective. More nuanced things like cache locality can be improved with an embedded data store rather than creating files and hoping the OS understands they will always be used together. More advanced things like retaining inverted indexes becomes possible and search performance is dramatically improved.

zbentley 9y ago
The shortest path to something like that (assuming it's a good idea) would probably not be writing an in-memory incremental compile state server, but storing intermediate artifacts as very cheap-to-serialize files (flatpak or just mmap and a cast), and then storing the files on /dev/shm or some other memory filesystem. That would give you most of the benefits you discussed (unless you clear out the cache/restart the machine) without requiring a huge rewrite of how state is stored. Most of the assumptions I'm making here are unverified, though, so take it with a large grain of salt.