Pierre Neidhardt <m...@ambrevar.xyz> writes:
> 3. Size of the database:
> I've persisted all locally-present store items for my current Guix version
> and it produced a database of 72 MiB. It compresses down to 8 MiB
> in zstd.
For comparison, my laptop’s store contains 1,103,543 files, excluding
.links 691,994. The updatedb database for all of them is 86MB and takes
~6 seconds to generate:
time updatedb \
--localpaths=/gnu/store \
--findoptions='( -path /gnu/store/.links -o -name *.drv -o -name
*.chroot ) -prune -o -type f -print' \
--output=/tmp/dbfile
locate -d /tmp/dbfile ecxc0800
(This could be further tweaked to exclude links…)
> The worse case is around (number of guix generations) x ~100 MiB.
This seems a little excessive.
> 4. Indexing speed:
> The above items took some 20 minutes to complete (on my rather
> powerful machine).
Oof. The updatedb hack above takes 6 seconds on my i7-6500U CPU @
2.50GHz with SSD.
I’m not suggesting to use updatedb, but I think it can be instructive to
look at how the file database is implemented there. We don’t have to
use SQlite if it is much slower and heavier than a custom inverted
index.
--
Ricardo
