[Yum-devel] depsolving work

[seth vidal]

On Wed, 2007-03-21 at 20:33 +0100, Tim Lauridsen wrote:
> seth vidal wrote: 
> > On Wed, 2007-03-21 at 19:28 +0100, Terje Røsten wrote:
> >   
> > > seth vidal
> > >     
> > > > Tim, Terje and Florian in particular, please check out latest cvs and
> > > > let me know where it screws up.
> > > >   
> > > >       
> > > Something strange is going on, I will try to explain what I saw:
> > > 
> > > Doing this (on rawhide i386):
> > > 
> > > # time echo n | python yummain.py -d100 -e100  install redhat-artwork > 
> > > /tmp/o.log
> > > 
> > > Gives:
> > > 
> > > Without patches: 11s
> > > With patches: 150s!
> > > 
> > > Not good.
> > > 
> > > With patches depsolving stops here:
> > > 
> > > looking at redhat-artwork as a requirement of ('metacity', 'i386', '0', 
> > > '2.18.0', '1.fc7')
> > > 
> > > After 60s (sic!) the next line is
> > > 
> > > looking to see what requires ('/usr/share/icons/Bluecurve/index.theme', 
> > > None, (None, None, None)) of redhat-artwork - 5.0.11-1.fc7.i386
> > > 
> > > 
> > > While the next line without patches is:
> > > 
> > > looking to see what requires ('/etc/gtk-2.0/gtkrc', None, (None, None, 
> > > None)) of redhat-artwork - 5.0.11-1.fc7.i386
> > > 
> > > And a lot of "looking to see what requires" lines which is not present 
> > > in with patches output.
> > > 
> > > So with patches a lot of files is skipped, however in some strange way 
> > > skipping is much more expensive.
> > >     
> > 
> > I think I know one thing about what's going on and I'm going to see if
> > comparing the lists as 'sets()' works fast enough or not.
> > 
> > -sv
> > 
> >   
> I was making some measurement and i saw the same problems with
> depsolving on redhat-artwork.
> but with the latest 1.144 revision of depsolve.py made the problems go
> away.

I swapped out the list for a dict and the look up is, of course, much
faster for large numbers of files/provides. 

I may put out a 3.1.5 with this for the moment and work on the
tuple_of_doom changes in 3.1.6 b/c it is more invasive.

suggestions welcome.

-sv