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
--
fedora-test-list mailing list
fedora-test-list@xxxxxxxxxx
To unsubscribe:
https://www.redhat.com/mailman/listinfo/fedora-test-list
