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!"