[pacman-dev] Holy inefficient batman!

[Xavier]

On Sat, Nov 17, 2007 at 05:55:44PM +0100, Nagy Gabor wrote:
> 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.

I actually hesitated when writing this. And I'm still confused.
Is it ok to have a 'cron>=2.0' dependency, but not providing 'cron 2.0' ?
Most versioned dependencies don't include any revisions.
See grep -r 'depends.*>=' /var/abs/core

> 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.

I indeed thought this was a negligency. It didn't seem to work for me.
For example when running the add045 pactest, I got messages like :
[19:17:19] debug: missing dependency '' for package 'pkg1'

I switched to alpm_dep_get_string usage and it worked fine.

> 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:
> http://www.archlinux.org/pipermail/pacman-dev/2007-November/010027.html
> 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.
> 

Yes, I saw that and I answered :
http://www.archlinux.org/pipermail/pacman-dev/2007-November/010033.html

For a more realistic usage like -Qt, I couldn't measure any differences.
It'll probably be easier to see a difference with smoke001, but is that
really problematic?

I didn't like that const strings were modified in _alpm_provision_cmp, so I
duplicated the strings.
And since the code im depcmp was similar, I did the same there, to keep
things consistent.

And I put a debug back because Aaron asked for it, and I also think it can be
very handy sometimes, to debug quicker.

> 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?
> 

Hm yes, I'll do more tests.