In GNOME 3.10 we’re encouraging more people to use the offline-update functionality which we’ve been using in Fedora for a little while now. A couple of people have told me it’s really slow, but I hadn’t seen an offline update take more than a minute or so as I test updates all the time. To reproduce this, I spun up a seldom-used Fedora 20 alpha image and let GNOME download and prepare all the updates in the background. I then added some profiling code to the pk-offline-update binary, and rebooted. The offline update took almost 17 minutes to run.
So, what was it doing all that time, considering that we’ve already downloaded the packages and depsolved the transaction:
| Transaction Phase | Time (s) |
| Start up PackageKit | 0.3 |
| Starting up yum | 3 |
| Depsolving | 10 |
| Signature Check | 8 |
| Test Commit | 5 |
| Install new packages | 704 |
| Remove old packages | 168 |
| Run post-install scripts | 90 |
This is about an order of magnitude slower than what I expected. Some of my observations:
- 10 seconds to depsolve an already depsolved transaction
- 8 seconds to check a few hundred signatures
- 168 seconds just to delete a few thousand files
- over 10 minutes to install a few hundred RPMs seems crazy
- 90 seconds to rebuild a few indexes seems like a huge amount of time
Some notable offenders:
| Package | Time to install (s) |
| selinux-policy-targeted | 122 |
| kernel-devel | 25 |
| libreoffice-core | 21 |
| selinux-policy | 17 |
| hugin | 12 |
| Package | Time to cleanup (s) |
| gramps | 11 |
| wireshark-gnome | 8 |
| hugin | 7 |
| meld | 6 |
| control-center | 5 |
Hopefully Fedora 21 will move to the hawkey backend, and we can get closer to raw librpm speed (which seems to be quite a speed boost) but even that is too slow. I’ll be looking into the individual packages this week, and trying to find what makes them so slow, and what we can do about them to speed things up.