[pacman-dev] Holy inefficient batman!

Nagy Gabor ngaba at bibl.u-szeged.hu
Sat Nov 17 11:55:44 EST 2007

> > On Sat, Nov 17, 2007 at 02:06:11PM +0100, Nagy Gabor wrote:
> > > > b) Could you also add some documentation about this in the man page
> > > > (especially that the format is name-space-version)
> > > 
> > > Well, I could add it (and now I really don't want to be lazy), but my
> > English
> > > is... you know.
> > 
> > I'm done now, I think I took care of all the comments/suggestions made. So
> I
> > added a little comment in PKGBUILD man page as well.
> > See chantry dot homelinux dot
> > org/~xav/gitweb/gitweb.cgi?p=pacman.git;a=shortlog;h=working
> > 
> > Sorry for not providing the url, but I did once, and noticed some bots are
> > looking for it now, and that annoys me :D
> > 
> Hmm. There are some interesting branches here... Especially the 'sync' one
> ;-)
> Now I'm going offline for this weekend, but I will vet you (and blame of
> course
> ;-P).
> Bye, ngaba
I'm writing from an internet caffee, because the results I found shocked me;-)
The blames (just joking):
1. "... 'cron 2.0' to satisfy the 'cron>=2.0' dependency of other packages.".
Only valid version numbers are allowed, for example 2.0-1.
2. I found a hidden alpm_dep_get_string _alpm_checkdeps patch in your patch:
Avoiding alpm_dep_get_string usage in debug messages was purposeful by me, not 
negligency (I refer to http://projects.archlinux.org/git/?
p=pacman.git;a=commit;h=d903fc607ee2aa2527202f1e54a44be325eabe48 here)
I don't want to waste time for formatting debug messages (I prefer only O(1) 
debug preformat), see also: 3.
3. I simply didn't understand why was alpm_splitdep so inefficient. The only 
thing I could imagine the horrible number of malloc/free calls:
alpm_depcmp is also an atomic function: smoke001.py calls it at least one 
million (!) times. That's why I tried to avoid free/malloc usage... (your 
patch duplicates the string instead of my ugly hack + preformat alpm_depcmp 
debug with alpm_dep_get_string). The same for _alpm_provision_cmp.

So I did some speed test, and the results was really suprising:
First of all, I kept only deps.c.diff from our patches (my typo doesn't matter 
here). And I did "pactest.py -v" on smoke001.py (empty disk cache, repeated 
many times times etc.)
The result: your patch is _significantly_ slower (I got 5,4,4,4, ... sec) than 
mine (I got 4,3,3,3, ... sec). I repeated the test 4 times (patch pacman, 
compile, 5 pactest); the result is always the same!
Could you test this, too?

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