Is it possible to speed up yum.

[Tim Lauridsen]

Patrick O'Callaghan wrote:
> On Thu, 2008-06-19 at 10:47 -0400, seth vidal wrote:
>> On Thu, 2008-06-19 at 09:46 -0430, Patrick O'Callaghan wrote:
>>> On Thu, 2008-06-19 at 09:21 -0400, seth vidal wrote:
>>>> The plugin that I'd point to first as having an impact pre-sack-setup
>>>> is fastestmirror. If you disable onlt that one do you see it?
>>> Looks fairly conclusive I would say.
>>> However /var/cache/yum/timedhosts.txt has only 126 entries, which
>>> shouldn't take more than a jiffy to read and parse. May be worth a look.
>>>
>> okay - it looks like fastestmirror isn't doing a 'good enough' check on
>> its mirror sorting. So on EVERY run it is rechecking those mirrors,
>> which means connecting to those 126 mirrors and determining the response
>> times.
> 
> What's the cache for then? The plugin seems to have no documentation (at
> least in the package) so it's hard to interpret what's going on without
> reading the code.
> 
>> So - on the original subject. With fastestmirror out of the list- how
>> are your result times from yum?
> 
> # time yum update
> Loaded plugins: protectbase, refresh-packagekit
> 0 packages excluded due to repository protections
> Setting up Update Process
> No Packages marked for Update
> 
> real    0m4.861s
> user    0m3.731s
> sys     0m0.291s
> #
> 
> I also repeated the test on Ubuntu:
> 
> $ time sudo apt-get upgrade
> Reading package lists... Done
> Building dependency tree
> Reading state information... Done
> The following packages have been kept back:
>   linux-headers-generic linux-image-generic
> 0 upgraded, 0 newly installed, 0 to remove and 2 not upgraded.
> 
> real    0m0.931s
> user    0m0.444s
> sys     0m0.056s
> %
> 
> So yum is now only 5 times slower than apt-get (real time) rather than
> 10 times as before.
> 

You can't compare this way it make no sense at all, you are comparing 
apples and oranges.
it like saying that drinking a glass of milk take 5 seconds and drinking 
a big bottle of water takes 50 seconds.
So milk it 10 times faster to drink that water.

the speed of yum has improved a lot it the latest releases, but the 
metadata also get bigger al the time, so there is more and more data to 
process. I some peoples eyes yum will never be fast enough before
every action takes 0s and i'm sorry to say that is not going to happen :)

I don't understand all that talk about speed, it is not the most 
impotent issues for me, features is.
if it takes 0.9 sec, instead of 0.3 sec, is not very impotent to me.
back in Fedora 6, a update to rawhide could takes 5 min, just for the 
depsolve, and in F9 the same action takes 16s to depsolve on my system.
So there you can talk about speed improvement.
Yes, off cause it would be faster to rewrite everything in assembler 
code, but it would be a nightmare to maintain. it gives a lot of benefit 
to use a high level language like Python, even if you losses a little 
speed.

Tim