[Aptitude-devel] looking at trimming aptitude times

[Daniel Hartwig]

[Moving to aptitude-devel@]

On 6 April 2013 22:05, nick black <nick.black at sprezzatech.com> wrote:
>
> first things first: at least in command-line mode (i.e., outside of
> fullscreen ncurses), could we defer reading package tags until doing so is
> definitely necessary? this would save us a nice chunk on the majority of
> operations,


Yes.  A simple and obvious optimization, patch welcome.

though doing so might be necessary for broader reasons than i
> imagine.
>

Doing what might be necessary?  Reading the debtags data?  It is a short
task to identify where the debtags data is used within aptitude, please
look and think before undertaking any work.

an strace -c of "aptitude install libopenexr2-dev" yielded the following:
>

*yawn*

this goes on for rather some time. if we handled tag lexing lazily, and it
> indeed usually isn't necessary, we cut this out without having to touch the
> lexing code. if we turn this into an mmap (with, if necessary, a sliding
> window sized to taste -- i presume this is the method of "dynamicmmap"?),
> we kill all those reads, and maybe tag lexing becomes fast enough that we
> don't care about it running.
>
> do either of these ideas excite anyone?


Excite? No.  It is a trivial matter to delay loading this data.  Send your
patch.

It does not interest me to optimize at the level of e.g. read vs. mmap.  It
is far more interesting to have reliable code that is simple to comprehend
and verify.


The next phase of aptitude development is focused on more serious matters,
such as integrating recent changes to apt behaviour and new libapt-pkg
tools, and architectural changes to resolve long-standing issues and
further improve the multi-arch interfaces.  This will involve disruptive
changes to the internal structure.  Optimizations like those proposed here
will generally not be considered at this time, however the debtags module
is rather self-contained and some work there is welcome.


Regards
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.alioth.debian.org/pipermail/aptitude-devel/attachments/20130407/d1ceaa42/attachment.html>