[Aptitude-devel] apt vs. SSD computers

Daniel Hartwig mandyke at gmail.com
Tue Dec 11 01:14:39 GMT 2012


TL;DR: aptitude is an order of magnitude slower than apt in startup
and shutdown times and it is a long known fact.  IMO solvable, see
below and discussions on the BTS for ideas.  If this disturbs you, use
apt-get where ever you can or run interactively.

One of these days I'm going to chop [these] in to little [FAQs]!

On 11 December 2012 07:18, Axel Beckert <abe at debian.org> wrote:
>> > OK, Bob, (sorry Otto) here's what happens when we hit Y to aptitude's
>> >
>> > "No packages will be installed, upgraded, or removed.
>> > 0 packages upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
>> > Need to get 0 B of archives. After unpacking 0 B will be used.
>> > Do you want to continue? [Y/n/?]"
>> >
>> > Which is the slowest thing I can recreate today.
>> > (It takes 28 seconds to do one big no-op.)

Should be a no-op, actually is not.  Currently aptitude will save it's
database of package states after most commands, whether it has done
something or not.  This is stored on disk in a textual format, so
reading and writing it take non-trivial amounts of time.

Some times, aptitude will also write and /re-read/ the database after an
operation.  Yes, really. :-(

[1] <http://bugs.debian.org/312920#30>

>
> Same here (EeePC 701, 680 MHz, 2 GB of RAM):
>
> aptitude full-upgrade  17.87s user 3.23s system 75% cpu 27.927 total
>
> (Fine for me though. I've got far slower boxes on which I run aptitude
> and are still happy with it. Of course I wouldn't mind if it would be
> faster though. :-)
>
>> I find aptitude to be extremely slow on any machine.

There are two areas where aptitude is much slower than apt.

APT uses a binary cache file for it's database of package states, so
does not have to compute or read much on startup.  Aptitude currently
scans in a textual database on every startup (and writes, re-reads on
shutdown as mentioned before).  In theory aptitude could also use
binary cache, although this is not desirable until the various issues
[2, 3] with package states have been resolved.

[2] <http://bugs.debian.org/137771>
[3] <http://bugs.debian.org/638049>

The aptitude problem resolver AKA dependency solver performs an
exhaustive search over all options.  Although it attempts to
prioritize optimal search paths and will return early, it remains more
complex than apt's solver.  This only comes in to play when there are
conflicts or broken backages.

>
> Depends. It get's annoyingly slow due to swapping below 64 MB of RAM.
> But above, it's IMHO generally fine for what it does.

Yes, and most package management operations are relatively infrequent.
The command line the performance compared to apt-get is notably poor,
but that is largely tied to startup costs that become irrelevant
in the interactive interface.

None-the-less, this is high on the list of priorities but lower than
issues related to auto-installed and held packages.

If you like to use aptitude most of the time but are disturbed that
“aptitude upgrade” takes tens of seconds, then use apt-get for that
operation, it is practically equivalent.  If it presents to you some
long list of installs and potential conflicts, then you can abort
and swap to aptitude.  Likewise for basic “install package-foo”
operations.  Be smart about it!

… or send a big patch; we like the big patch.

Regards



More information about the Aptitude-devel mailing list