[Yum] Re: why doesn't yum cache anything?

[Farkas Levente]

seth vidal wrote:
> On Fri, 2004-12-31 at 00:12 -0800, Jamie Zawinski wrote:
> 
>>Sean Middleditch wrote:
>>
>>>It only takes a handful of seconds on my machine, which is only 1.5ghz.
>>>Yum is *very* RAM intensive, so if you're low there, that might be the
>>>slow down...?
>>
>>By "a handful of seconds" do you mean "20"?  I think an acceptable 
>>number would be, like, "3", but I'm seeing anywhere from 19 to 64, 
>>on four different FC3 machines on two different networks:
>>
> 
> 
> 
> 
> on my speedstepped to 600mhz laptop with 768M of ram:
> 
> time yum list '*mtr*'
> Setting up Repo:  updates-released
> Setting up Repo:  extras
> Setting up Repo:  base
> Reading repository metadata in from local files
> updates-re: ################################################## 408/408
> extras    : ################################################## 623/623
> base      : ################################################## 1652/1652
> Installed Packages
> mtr.i386                                 2:0.54-10
> installed
> Available Packages
> mtr-gtk.i386                             2:0.54-10              base
> 
> real    0m16.929s
> user    0m5.974s
> sys     0m0.531s

both of you has right. jwz as an old hacker _feel_ there is something 
wrong with it. and he's right. yum is something an ms's product do not 
realy care about system resources and assume everyone has enough(?) cpu 
and memory. the new metadata format is questionable. not at the server 
side (but many people argue about it, see the thread about the smart 
package manager), but on the client side! even if the server use that 
xml format, because assume more different client will access to the same 
repo (like yum, up2date etc) why yum has to keep the xml data localy why 
can use a different sructure in the local cache? i hope the files like: 
primary.xml.gz.4efa5cf08ac4f47d510653cd61128a688bc39188.pickle are the 
binary representation of the xml data, but even in this case the local 
cache file can be separated into different files (eg. in most case the 
package description is not required why all packages description is 
loaded, and there are many other mostly unused data). in this case this 
time probably can be decrease down to a few seconds. and the situation 
linear with the number of repos.
on the other side i understand seth's position, that first create a 
feature rich complete and bug-free version somewhere 2.1 or 2.2. but 
it's clear to everyone that the most anoying think with you it's speed, 
both at startup/load time and both at dependencie resolution time. so 
imho it'd be nice to look into this problems soon. something like the 
bootchart challenge would be useful in case of yum speed.
yours.

-- 
   Levente                               "Si vis pacem para bellum!"