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?