Description of problem: In my recent experiments with dnf I had a distinct impression that overall dnf is awfully slow. So I decided to measure it. Timing on a rawhide installation 'dnf check-update' I got real 2m35.460s user 0m47.703s sys 0m16.589s For 'yum check-update' I got (a drum roll): real 0m33.838s user 0m12.208s sys 0m5.386s Here goes away, in practical terms, a supposed speed advantage of dnf in dependecies resolution. There was 66 packages in new updates. As it happens both dnf and yum in this case had to retrieve a complete new metadata. It looks to me that dnf always throws away all older metadata so in cases where some of that can be kept and only few updates are installed, which in practice is very often the case, yum will be even further ahead as it selectively refreshes only those metadata which are required. Version-Release number of selected component (if applicable): dnf-0.4.19-1.fc21
The time to decompress the metadata vs depsolving speed is a tradoff most our users agree to be a good one. We can however get some speedups from background processing as described in bug 1038824. DNF does not throw away valid (nonexpired) metadata. *** This bug has been marked as a duplicate of bug 1038824 ***
"Decompression" takes about 1 sec, so that can't make the difference here. This must be some download issue, maybe dnf picked a slow mirror or something like that. Michal, do you get that kind of slowness all the time? Maybe the logs contain some hint to why dnf's download is so slow.
(In reply to Michael Schröder from comment #2) > Michal, do you get that kind of slowness all the time? It was prominent enough and prevalent enough to cause me to try to get some data instead of relayin on an impression of a general slugishness. One or two incidents I would dismiss for "just beeing unlucky". I did not need any "heroic efforts" to get quoted times. Just measured what came. > Maybe the logs contain some hint to why dnf's download is so slow. I did not find anything in particular but dnf seems to be very frugal with providing an information. I noticed "extra" files rawhide-filenames.solvx, rawhide.solv and @System.solv together worth around some 47 Megs. Just FYI - my rawhide system is behind a resonably fast, at least on a download side, "home" cable connection but this is definitely not a T1 link. Usually "fast enough" although mirror responses could definitely be a factor. Likely my link is somewhat better than what would be "typical" for a "home connection" in North America.
(In reply to Michael Schröder from comment #2) > "Decompression" takes about 1 sec, so that can't make the difference here. > This must be some download issue, maybe dnf picked a slow mirror or > something like that. Michal, do you get that kind of slowness all the time? > Maybe the logs contain some hint to why dnf's download is so slow. by 'decompressing' I meant 'processing', i.e. the time that libsolv is doing the heavy lifting going through xmls and building repodata. interleaving this with the downloads should give some nice speedups.