...and I don't mean the download speed. I mean the whole transaction business when it's already local. No fast mirror would help.
Posting this in rawhide, because I'm on rawhide, and I'm using yum 3.4.3 from there.
Let's say I have a relatively modern machine. It's a Thinkpad Edge laptop, dual Neo L325 CPU, eight (8) gigs of RAM (so no one gets me started on too little RAM), and a generic species of 5400rpm hard drives.
Take, for example, installing a small package.
time sudo yum -y install telnet
The thing starts thrashing my hard drive for no apparent reasons, then install a package which has got 61 KiB in size (while thrashing furiously, mind you), then thrash again for… (drum roll) the whole total of (drum roll) (it's still thrashing as I'm writing this)
It's SEVEN. Freaking. Minutes. All of them. To install 61 kilobytes worth of just one package. On a modern machine.
I suspect yum developers have never ever tried to use it on anything weaker than an OCZ PCIe SSD, or a SAS RAID array.
Yes, I know about that bug
. Unfortunately, it's almost two years since it was open, it was closed since, but the cause for which it was closed was long ago forgotten, it seems.
Because the cause for slowdowns remains the same: the whole RPM database is being read all over, over and over.
Quoting from the bug comments:
2. The new rpmdb caching requires a "what state/version/whatever is the rpmdb"
so we can know when we have to invalidate our cache (either because we screwed
up, or someone altered the rpmdb from outside yum).
which kinda defeats the purpose of caching, which is SPEED in the first place. What else makes me suspicious is that this information is queried several times (namely, the version of rpmdb) during a yum run. During that run, the rpmdb is locked and it's quite obvious nobody, ever, would muck around with it.
Of course someone would defend the scheme by going on with technobabble on how the rpmdb works, but I seem remembering that for the same task, which is packages' installation, obsoleting and removal, Debian spends a fraction of that time. And if Fedora's scheme must require seven minutes for a single package, it means the scheme is totally broken.
Which makes me wonder just how competent yum developers are.