[Aptitude-devel] Bug#312920: writes when nothing should be written when nothing should be written)

[Manuel A. Fernandez Montecelo]

Some comments about previous messages in this report... perhaps of
little importance now, but here they are for posterity...


2012-03-21 23:57 Daniel Hartwig:
>reopen 312920
>thanks
>
>[...]
>Further you have misread the intent of "writes when nothing should be
>written" as meaning "please do not display so much output."  Rather,
>it refers to the writing and subsequent re-reading of the package
>database *after* aptitude has determined there is nothing to do--this
>action takes a relatively long time to perform and is of questionable
>utility.

FWIW, the extra writing of the state files happens because of bug
#429732.

Trying to improve this to gain fractions of a second and risking to fall
again in old bugs is not worth doing at this point, in my opinion.


>> I agree that 2s is far more time that it should be desirable, but yet
>> it's 2s and nobody is going to die because of that.
>
>2 s or 29 s is not important--such a figure will differ widely between
>various systems--it is the relative performance that is of interest.
>You will notice I provided the times for both aptitude and apt-get on
>this command.

Comparing apt and aptitude is not fair in this case, because aptitude
provides several extra functionalitities that need more resources than
apt (like detecting the "new" packages available; debtags; user tags; or
locking different directories for the session) that need initialising
for most common operations (specially the curses mode / interactive
sessions, that apt doesn't need); or are needed for these extra
functionalities of aptitude that are used very often (like the mentioned
"new packages available", or pattern matching, or policies for grouping
of packages in different lists).

I never used aptitude in systems where it took so long to do operations
as ~30s, even if I used it in small devboards with MIPS processors for
example, and the computers where I took the measurements were/are not
exactly bleeding edge.

In any case, the difference between apt and aptitude was not an order of
magnitude bigger in my measurements, and the max time of aptitude doing
this was 2 to 4s compared to 0.5 to 2s of apt.  So I wouldn't
automatically assume that aptitude is doing much worse.


>This bug report is not about performance in general.  It is directed
>at the performance of a specific command and contains constructive
>suggestions that can certainly be implemented which would improve the
>performance.
>
>So the original report, with comments added:
>
>> The following command takes a long time to execute.
>
>> It should read very little,
>
>This code is executed twice yet in theory only need be done at the
>start because nothing has changed:
>
> Reading Package Lists... Done
> Building Dependency Tree
> Reading extended state information
> Initializing package states... Done

I made some changes lately that might have helped this processing of
information twice.

In any case, with the to-be-released version, the time and messages are
now:

  time aptitude install does-not-exist | cat
  Reading package lists...
  Building dependency tree...
  Reading state information...
  Reading extended state information...
  Initializing package states...
  Writing extended state information...
  Building tag database...
  Unable to apply some actions, aborting
  Couldn't find any package whose name or description matched "does-not-exist"

  real    0m1.563s
  user    0m1.192s
  sys     0m0.364s


>> compute very little,
>
>There are two computations happening:
>
>* after not finding a package with the exact name
>"some-package-that-does-not-exist" two searches are performed:
>  - ?name(some-package-that-does-not-exist); and
>  - ?description(some-package-that-does-not-exist)
>
>* the set of kept-back packages is computed, even though no packages
>to install were identified.
>
>The second is certainly of little utility when aptitude has failed to
>identify the requested package.  The first is an automatic search
>attempt, but it may be preferable to simply abort with an error and
>let the user direct their own search manually if desired.

I think that it's worth it, and a nice functionality that it takes the
initiative to do some searches that might help the user to save more
seconds and typing in looking for alternatives, or discover relevant
packages that would not have seen otherwise:

  time aptitude install -s Krita
  Couldn't find any package matching "Krita", but there are 11 packages
  which contain "Krita" in their description:
    calligraauthor calligraauthor:i386 icc-profiles krita krita:i386
    xicc xicc:i386 krita-data icc-profiles-free krita-gemini
    krita-gemini:i386
  Unable to apply some actions, aborting

  real    0m1.388s
  user    0m1.068s
  sys     0m0.316s


And regarding the kept-back packages, it does not happen now due to
other changes already mentioned (aborts at the first failure).


It is debatable whether the behaviour before was helpful; but in
general, this is what aptitude historically did -- to try to continue
with actions when possible.  It was changed due to other reasons (not
providing accurate exit status when failing to install requested
packages, which are important for automation), but I think that
rethinking that behaviour due to *this* report in particular (just a
matter of performance in some systems) is not worth it.


>> and write absolutely nothing.
>
>This refers the writing of the *unchanged* packages database as well
>as the list of kept-back packages.  Given the emphasis placed on speed
>in the report, I'd say it is more the former because that takes
>considerable time.

Explained above about writing the unchanged database.


>The net effect of these suggestions is to have aptitude behave similar
>to apt-get in this situation:
>
>a. read package db
>b. determine there is no package named x
>c. STOP
>
>Instead, there is currently a lot of processing and useless saving of
>the db whic
>[ORIGINAL ENDS LIKE THIS]

I don't think that aptitude should mimic apt-get.  For apt-get we
already have apt-get, and if there's some advantage of aptitude is the
extra functionality, otherwise people would be better off using apt-get.
It's faster and better maintained, if nothing else.

On the other hand, it would be possible to strip absolutely everything
unnecessary, and in that case it would behave almost like apt-get
initially [*]; and then load more stuff needed for other functionality
as needed.

I did some of that in recent commits, to address this bug report, like
lazy initialisation of "tasks" that took 0.3 to 0.4s.  But other things
like loading debtags (needed in all interactive operations, pattern
matching, "show" command...) take only 0.1s.

So there are not so many areas left to optimise other than avoiding to
read pkgstates (needed for "new", user tags, forbid-versions and other
things anyway).


[*] not /quite/, because aptitude would have to do *all* what apt does,
    plus read its specific config (disk access is slow) and
    initialisation of derived classes using libapt, linking with more
    libraries, etc, but let's pretend...


Cheers.
-- 
Manuel A. Fernandez Montecelo <manuel.montezelo at gmail.com>