[pacman-dev] [PATCH 0/2] Remove REQUIREDBY usage

Nagy Gabor ngaba at bibl.u-szeged.hu
Tue Nov 13 13:47:43 EST 2007


Idézés Dan McGee <dpmcgee at gmail.com>:

> On Nov 13, 2007 7:05 AM, Nagy Gabor <ngaba at bibl.u-szeged.hu> wrote:
> > Hmm. Great job.
> > I'm a bit doubter about alpm_splitdep: did you empty disk cache before
> retest?
> > If you did so, this is really surprising to me: this is obviously a
> speed-up,
> > but that is _much_ greater than I expected.
> > Hmm.
> >
>
http://projects.archlinux.org/git/?p=pacman.git;a=commit;h=7653bb93997f52848b54ab80868cd6da52808a75
> > we can spare the first strdup, if you backup *ptr then reset before
> return.
> >
> > Some other suggestions:
> > 1. compute_requiredby now can return with an alpm_list of pmpkg_t* -s, and
> then
> > we needn't scan pkgache to find 'pkgname' in deptest
> > 2. -Qt needn't compute all the requiredby packages, it can stop if he find
> the
> > first requiredby (no orphan).
> > ...
> > Summary: the results are very promising for me ;-)
> 
> pacman is the last pacman-git release (before any requiredby changes),
> src/pacman/.libs/pacman is with the compute_requiredby only.
> 
> [root at dublin pacman]# sync; echo 3 > /proc/sys/vm/drop_caches; time
> pacman -Qt > /dev/null
> real    0m10.698s
> user    0m0.060s
> sys     0m0.160s
> [root at dublin pacman]# sync; echo 3 > /proc/sys/vm/drop_caches; time
> ./src/pacman/.libs/lt-pacman -Qt > /dev/null
> real    0m11.327s
> user    0m0.607s
> sys     0m0.127s
> 
> The above results tell me at least one thing. We don't have to worry
> about optimizing pacman -Qt by stopping early- it isn't worth the
> hack.
Any notable optimization worth the hack. And implement compute_requiredby_first
is quite trivial. My estimated speed-up (only compared to compute_requiredby) is
at least 2x.
> [root at dublin pacman]# sync; echo 3 > /proc/sys/vm/drop_caches; time
> pacman -Qi pacman-git > /dev/null
> real    0m0.686s
> user    0m0.020s
> sys     0m0.027s
> [root at dublin pacman]# sync; echo 3 > /proc/sys/vm/drop_caches; time
> ./src/pacman/.libs/pacman -Qi pacman-git > /dev/null
> real    0m10.712s
> user    0m0.047s
> sys     0m0.147s
> [root at dublin pacman]# time ./src/pacman/.libs/pacman -Qi pacman-git >
> /dev/null
> real    0m0.060s
> user    0m0.033s
> sys     0m0.023s
> 
> OK, so -Qi performance takes a big hit when nothing is cached, because
> we actually have to load the whole DB to show the one requiredby line.
> However, note that its performance when the kernel FS cache is
> available is quite fast, so we have nothing to worry about there.
> 
> [root at dublin pacman]# sync; echo 3 > /proc/sys/vm/drop_caches; time
> pacman -Su > /dev/null
> real    0m4.573s
> user    0m0.490s
> sys     0m0.533s
> [root at dublin pacman]# sync; echo 3 > /proc/sys/vm/drop_caches; time
> ./src/pacman/.libs/lt-pacman -Su > /dev/null
> real    0m4.848s
> user    0m0.487s
> sys     0m0.550s
> 
> No difference here (note that this was a sysupgrade with no upgrades
> available, so I don't think requiredby is even needed here).

> [root at dublin pacman]# sync; echo 3 > /proc/sys/vm/drop_caches; time
> yes "no" | pacman -Su > /dev/null
> Proceed with installation? [Y/n]
> real    0m13.979s
> user    0m0.533s
> sys     0m0.723s
> [root at dublin pacman]# sync; echo 3 > /proc/sys/vm/drop_caches; time
> yes "no" | ./src/pacman/.libs/lt-pacman -Su > /dev/null
> Proceed with installation? [Y/n]
> real    0m14.467s
> user    0m0.507s
> sys     0m0.623s
> 
> No huge difference here (sysupgrade with one upgrade available- qt3).
> 
> If anyone else can think of places where this switch to
> compute_requiredby code would really hurt us, I'd be glad to hear it.
> 
compute_requiredby mostly has negative impact in case of removals: I would try
-Rs, [-Rc <- why do we have such dangerous stuffs ? ;-], -R "many packages"; and
so on.

Bye, ngaba


----------------------------------------------------
SZTE Egyetemi Könyvtár - http://www.bibl.u-szeged.hu
This mail sent through IMP: http://horde.org/imp/





More information about the pacman-dev mailing list