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