[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: looking at trimming aptitude times

[Moving to aptitude-devel@]

On 6 April 2013 22:05, nick black <nick.black@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

Yes.  A simple and obvious optimization, patch welcome.

though doing so might be necessary for broader reasons than i

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:


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.


Reply to: