[Yum-devel] depsolving work

[Tim Lauridsen]

seth vidal wrote:
> 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
>
>
> _______________________________________________
> Yum-devel mailing list
> Yum-devel at linux.duke.edu
> https://lists.dulug.duke.edu/mailman/listinfo/yum-devel
>   
Just put out a 3.1.5.

I made some more measurements with yumex. see the attached outputs.

Summary:
head : 20s.
314 :   23s
311:    46s (2s in second run, with all headers in cache, not a very 
usual case)

Tim


Tim
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.baseurl.org/pipermail/yum-devel/attachments/20070321/b28e29fb/attachment.htm 
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: yumex-yum-311-1run.txt
Url: http://lists.baseurl.org/pipermail/yum-devel/attachments/20070321/b28e29fb/attachment.txt 
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: yumex-yum-311-2run.txt
Url: http://lists.baseurl.org/pipermail/yum-devel/attachments/20070321/b28e29fb/attachment-0001.txt 
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: yumex-yum-314.txt
Url: http://lists.baseurl.org/pipermail/yum-devel/attachments/20070321/b28e29fb/attachment-0002.txt 
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: yumex-yum-head.txt
Url: http://lists.baseurl.org/pipermail/yum-devel/attachments/20070321/b28e29fb/attachment-0003.txt