[pacman-dev] back-end speed, desc files (was: pacman -R speed-up)

Nagy Gabor ngaba at bibl.u-szeged.hu
Sun Jul 6 06:52:13 EDT 2008


Hi!

OK. We saw, that we should load as few desc files as possible. We can
gain one more benefit if we reduce desc file read (over speed-up): we
spare some memory (we have "on-demand" pkgcache, once we read desc, it
will stay in memory...). Btw, desc files are for packager, build date,
etc. not to load them for usual operations (they are quite long,
anyway) imho.

We get many complaints about pacman speed... (Khm. These complaints
are valid.)

I did some tests, and I found that pacman -S and pacman -R is not so
bad (~10 sec on my machine with empty cache; I'm testing -S with -Sp
always).

But -Su is quite "terrible", simply 0.5-1 min (-Sup!).
I did some debugging, I found that all desc files are read in sync.
Why?
alpm_sysupgrade:
1. %REPLACES%
2. %FORCE% (this is reason for the "installed" syncpkgs only)
If you are unlucky, pacman reads many depends files in sync.
Why?
resolvedeps:
The search for literal rule is crucial here. get_frompkgcache is fast,
because it doesn't require desc, depends or files. And in most cases
the found literal is a satisfier. You are unlucky, if resolvedeps must
search for provision (freeglut provides glut), then pacman will read
depends files until it finds the provision. (So quick tip for packagers:
Use literal package in %DEPENDS%, if possible ;-)

I hacked my pacman, I disabled 1. and 2. Result: _3 times_ faster -Sup.

I just brought this up, maybe somebody have an idea about faster
implementation of 1. and 2. (it's easier to modify syncdbs than
localdb) and maybe this why pacman reads db files discussion was
interesting.

Bye

PS: Status of FS#8586. Speed tests there?




More information about the pacman-dev mailing list