[pacman-dev] [RFC] pactree rewrite in C

[Dave Reisner]

On Mon, Oct 11, 2010 at 04:49:00PM +0200, Xavier Chantry wrote:
> On Mon, Oct 11, 2010 at 3:32 PM, Dan McGee <dpmcgee at gmail.com> wrote:
> > On Mon, Oct 11, 2010 at 8:06 AM, Dave Reisner <d at falconindy.com> wrote:
> >> The recent patchwork over the weekend inspired me to take a closer look
> >> at pactree. My first impression was that it would be a great candidate
> >> for a rewrite in C.
> >>
> >> http://www.github.com/falconindy/pactree
> >>
> >> Results are entertaining:
> >>
> >> # bash version
> >> $ time pactree -r glib2 >/dev/null
> >>
> >> real    0m2.538s
> >> user    0m1.593s
> >> sys     0m0.435s
> >>
> >>
> >> # C rewrite
> >> $ time ./pactree -r glib2 >/dev/null
> >>
> >> real    0m0.016s
> >> user    0m0.007s
> >> sys     0m0.009s
> >>
> >>
> >> I'm finding that it's even slightly more accurate than the bash version
> >> WRT to reverse dependency tracking as it's hooking into alpm's
> >> alpm_pkg_compute_required_by() instead of wandering through the file
> >> hierarchy.
> >>
> >> It's feature complete compared to the Bash version, aside from the
> >> export to graphviz. The only functional change I've made is: when
> >> walking reverse depends, don't re-walk already visited dependencies. I
> >> thought this was a logical change given the behavior of the standard
> >> dependency tracking.
> >>
> >> I'm happy to offer this up for merging if desirable. There's a few ugly
> >> bits in the code I still want to refactor -- if anyone has any comments
> >> or criticisms, they're very welcome.
> >
> > Didn't look at the code yet, but:
> > 1. Tools that look at the database directly are bound to be broken in
> > the near future anyway- some of this stuff is going to get redone, so
> > we should be doing all interaction via libalpm.
> > 2. As far as graphviz/dot, I think the feature would be more
> > interesting anyway if it just generated the graphviz input rather than
> > actually invoking graphviz. That should be easy to implement.
> >
> > So I at least give a +1 to this, and we can move it into src/util/
> > like vercmp to make it easier to build and such.
> >
> 
> This looks awesome.
> 
> Here is my benchmark :
> pactree -r glibc :
> 1m37.494s -> 0m0.329s
> 
> Also the -r output deals correctly with providers.
> 
> The only drawback I could find is that arguments cannot be providers.
> [xavier at xps-m1530 pactree (master)]$ pactree cron
> +--dcron provides cron
>    |--glibc
>       |--linux-api-headers
>       |--tzdata
> [xavier at xps-m1530 pactree (master)]$ ./pactree cron
> error: package 'cron' not found
> 
> Anyway Dave, it would be great if you could integrate this in
> src/utils, have a look at Makefile.am for the defines you can re-use
> (dbpath and/or config). Maybe you can keep it simple and just use
> DBPATH as I did in testdb.
> 
> And as a bonus, keep generation of graphviz input file (or similar
> graph tool) and provider feature :)
> 

Oooh, thanks for the reminder -- I had meant to resolve command line
args as providers and never got around to it. I'll need to read up on
dot's graph specification language. My next project needs to revolve
around increasing the number of hours in a given weekend.

d