speeding up portage’s metadata cache
26.02.2015 by Dirk OlmesGentoo’s portage keeps metadata about installed ebuilds in /var/cache/edb
. Dependency info for all installed ebuilds is in a dep
subdirectory which typically looks something like this:
.
├── usr
│ └── portage
│ ├── app-admin
│ │ ├── eselect-1.4.1
│ │ ├── eselect-lib-bin-symlink-0.1.1
│ │ ├── eselect-opengl-1.2.7
│ │ ├── gamin-0.1.10-r1
│ │ ├── logrotate-3.8.7
│ │ └── perl-cleaner-2.16
...
When portage needs to process dependency info, it reads those files. On a normal system, you will have a couple of hundred packages installed. This means that dependency processing does quite a bit of file processing.
Now if that dependency info was stored in some kind of database, wouldn’t that speed up dependency processing?
I stumbled over a wiki page describing how to switch portage’s metadata cache to sqlite. Even the portage man page talks about this - try running man portage
and read the section about the modules
file.
So I gave the sqlite metadata cache a try to measure if it really speeds up portage. After configuring the database and rebuilding the metadata cache, /var/cache/edb/dep
looks a bit different now:
.
└── usr
├── portage
└── portage.sqlite
Now let’s get to the interesting part: does the database really speed up portage? To measure, I ran a couple of emerge -vp
commands using the normal setup and again using the database. The results are quite disappointing, though:
The best improvement was about 6% with the metadata database.
57% of the ebuilds did run slower with the metadata database, the worst increase was about 43%
So it looks like fiddling with portage’s metadata cache is not really worth the hassle.
Comments
There are no comments yet.