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

looking at trimming aptitude times



howdy, all. i'd like to bring down aptitude times, understanding that a
rewrite here is out of the question :). this would all be surgical work.

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, though doing so might be necessary for broader reasons than i
imagine.

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

% time     seconds  usecs/call     calls    errors syscall
------ ----------- ----------- --------- --------- ----------------
 57.83    0.057515           0   4396888         2 read
 24.31    0.024181         465        52         1 wait4
 12.07    0.012000        1714         7           msync
  4.02    0.004000         108        37           pselect6
  0.99    0.000988          62        16           clone
  0.72    0.000714           0     80916           write
  0.06    0.000056           0       133           brk
  0.00    0.000000           0       168        25 open
  0.00    0.000000           0       191           close
  0.00    0.000000           0       691       250 stat

nothing below the msync is worth thinking about right now, and really our
syscall performance is pretty solid; most of the time aptitude burns is in
userspace. those reads are a bit...well, there's a lot of reads. the wait4s
are probably easier to get a speedup from, as they're heavyweight (those
times, according to strace(1), are system and not wall), but whatever.

looking at a strace, we see...

open("/var/lib/debtags/package-tags", O_RDONLY) = 25
fcntl(25, F_SETFD, FD_CLOEXEC)          = 0
read(25, "0", 1)                        = 1
read(25, "a", 1)                        = 1
read(25, "d", 1)                        = 1
read(25, ":", 1)                        = 1

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? if so, i can drop a patch to kick
this effort off.

-- 
nick black     http://www.sprezzatech.com -- unix and hpc consulting
to make an apple pie from scratch, you need first invent a universe.

Attachment: signature.asc
Description: Digital signature


Reply to: