reopen 312920 thanks On 21 March 2012 18:36, Manuel A. Fernandez Montecelo <manuel.montez...@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 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
