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

[Daniel Hartwig]

reopen 312920
thanks

On 21 March 2012 18:36, Manuel A. Fernandez Montecelo
<manuel.montezelo at gmail.com> wrote:
>
> I put the emphasis on the title of the bug report, "writes when
> nothing should be written".  The comment about taking long to execute
> for me is secondary, a subproduct, a side-comment.
>

You need to be considering all of the issues mentioned in the report,
subsequent discussion, and any merged reports.  The title is just a
summary; the very first line identifies the point of concern as "The
following command takes a long time to execute."

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.


> 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.

> All of the
> initialisation process is suboptimal (according to comments to
> dburrows in other bug reports), it should be addressed separately and
> comprehensively and for many commands, not just when the package is
> not found, IMO.
>
> In other words, the speed issue is not especific a problem that
> happens when the package is not found, but a general problem of
> aptitude, so I don't think that this bug report should be kept open
> because of that.
>

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

> 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.

> 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.


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