Idézés Nagy Gabor <ngaba@bibl.u-szeged.hu>:
Hi! When I started to work with pacman, I also hated this db structure, because of its inefficiency. But now, I'm not sure that it is inefficient. I don't have too much experience with "dbms"s, but after pkgcache is loaded, I cannot imagine radically faster solution than the current[*]. So we should compute the full-load-time of the pkgcache, my guess: 3-4 sec. Which is not too much (in case of -Su for example); but I'm sure that this will be less then running pkgconfig. So we are talking about seconds; and I dunno if the db change would worth the effort. I'm not sure that would be even faster (see [*]) (keeping pkgcache is needless with a dbms imho). I remember the results of my "time pacman -R foo" tests (after empty disk cache): "running ldconfig" caused at least 60% (!) of the running time. Then I said: ok, we can speed up this a bit, but we won't see anything (because of ldconfig) However, we can speed up the "pkgcache loading time" of sync repos, as Vmiklos said. Bye, ngaba
Hi! I attached some speedtest results; I hope that this is not offtopic here. As I see, this is clearly what I predicted (except: ldconfig is much faster than I remembered): Loading pkgcache time is about 10 sec; after it is loaded working with pkgcache is very fast (see the last two tests for example). So IMHO the _constant_ ~10 sec we can win with a new db backend is not notable with large (-Su) transactions. So personally I can live with the current backend. Note: my system is quite lightweight... Bye PS: As I wrote in the subject, analyzing pacman's speed would be much easier if debug printed timestamps to log (on request?). What do you think about this? If you like it, I will create a patch (~0 effort work.) ---------------------------------------------------- SZTE Egyetemi Könyvtár - http://www.bibl.u-szeged.hu This mail sent through IMP: http://horde.org/imp/