[pacman-dev] speed tests + timestamps

[Nagy Gabor]

Idézés Nagy Gabor <ngaba at 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/
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: results.txt
URL: <http://archlinux.org/pipermail/pacman-dev/attachments/20071112/5137a848/attachment.txt>