3 ms·

I am really surprised that something as frequently used as apt had these obvious performance issues. Was there a technical reason for it? I noticed that it ran

I am really surprised that something as frequently used as apt had these obvious performance issues. Was there a technical reason for it? I noticed that it ran painfully slow on devices with slower disks. I suppose that is going to change now.

devit 11y ago
Based on the sort of issues fixed, it looks like no one ever bothered to benchmark it until now.
- buster 11y ago
  As a Debian user, i find that updating can be slow, but it looks like spending much of its time on network traffic. Also 30 or 40 seconds is not large enough to be _really_ annoying. Nevertheless, i'm looking forward to this!
jzwinck 11y ago
A 20x speedup as reported here is not that unusual in my experience. If I work on optimizing something which has never had detailed performance analysis, I expect to achieve 3x to 10x speedups in most cases. Even 100x is not really rare. I once found a similar thing in a commercial setting. A program had been written which could set one bit in a shared memory region for use as a feature flag. It was slowly expanded in use until it was being run thousands of times a day on hundreds of very expensive computers. I wrote a replacement program which read commands from a file and set all the bits in one invocation. This saved well over 100k USD per year if you just added up the cost of computer time without staffing. I imagine this APT fix is worth more than that.
deleted 11y ago
[deleted]
thrownaway2424 11y ago
I doubt this is by any means the most important performance issue that Debian package installation faces. It looks like the speedup discussed here is in the no-update case, which is nice, but not the only case. I stopped using Debian at home several years ago, and one of the main reasons was the incredible slowness of groping around in GNOME's moronic XML settings database during every update. Upgrading schemas and whatnot. I still use Debian at work and I note that it is still prone to building and rebuilding initrd during an update when it should only be built once. On a recent update initrd was built for the kernel that was being _uninstalled_ which was awesome.
- kasabali 11y ago
  consider using eatmydata. living on the edge but it is worth it. https://packages.debian.org/jessie/eatmydata https://packages.debian.org/jessie/eatmydata
newman314 11y ago
Apt is quite slow on a Pi running OSMC so I'm hoping this makes it downstream at some point
kasabali 11y ago
> I noticed that it ran painfully slow on devices with slower disks. I suppose that is going to change now No, most of the time is spent fsync'ing and it is a problem at a lower layer (related to dpkg), but ot apt. Too many bug reports to list but see [0] for the latest one. You can use apt with eatmydata as a workaround. [0] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=613428 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=613428

devit 11y ago

Based on the sort of issues fixed, it looks like no one ever bothered to benchmark it until now.

buster 11y ago
As a Debian user, i find that updating can be slow, but it looks like spending much of its time on network traffic. Also 30 or 40 seconds is not large enough to be _really_ annoying. Nevertheless, i'm looking forward to this!

jzwinck 11y ago

A 20x speedup as reported here is not that unusual in my experience. If I work on optimizing something which has never had detailed performance analysis, I expect to achieve 3x to 10x speedups in most cases. Even 100x is not really rare. I once found a similar thing in a commercial setting. A program had been written which could set one bit in a shared memory region for use as a feature flag. It was slowly expanded in use until it was being run thousands of times a day on hundreds of very expensive computers. I wrote a replacement program which read commands from a file and set all the bits in one invocation. This saved well over 100k USD per year if you just added up the cost of computer time without staffing. I imagine this APT fix is worth more than that.

deleted 11y ago

[deleted]

thrownaway2424 11y ago

I doubt this is by any means the most important performance issue that Debian package installation faces. It looks like the speedup discussed here is in the no-update case, which is nice, but not the only case. I stopped using Debian at home several years ago, and one of the main reasons was the incredible slowness of groping around in GNOME's moronic XML settings database during every update. Upgrading schemas and whatnot. I still use Debian at work and I note that it is still prone to building and rebuilding initrd during an update when it should only be built once. On a recent update initrd was built for the kernel that was being _uninstalled_ which was awesome.

kasabali 11y ago
consider using eatmydata. living on the edge but it is worth it. https://packages.debian.org/jessie/eatmydata https://packages.debian.org/jessie/eatmydata

newman314 11y ago

Apt is quite slow on a Pi running OSMC so I'm hoping this makes it downstream at some point

kasabali 11y ago

> I noticed that it ran painfully slow on devices with slower disks. I suppose that is going to change now No, most of the time is spent fsync'ing and it is a problem at a lower layer (related to dpkg), but ot apt. Too many bug reports to list but see [0] for the latest one. You can use apt with eatmydata as a workaround. [0] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=613428 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=613428