Re: Speeding up aptitude on NSLU2
On 4/28/08, Kurt Pruenner <leak@gmx.at> wrote:
> starting aptsh is a matter of seconds, while
> starting aptitude is a matter of minutes... :(
On a 600MHz machine with a (slow) hard disk, aptitude takes 4.5
seconds to start up and close down, while on a 200MHz NFS or USB
system it takes over two minutes.
A lot of this time it is I/O bound, reading the various text files
containing package data, as you can see by saying
# time aptitude
- the "real" time far exceeds the "user+system" times, and 40% of the
CPU time is spent in the kernel.
Part of this is due to an over-clever "optimisation" of the reading of
the text files in libapt-pkg (source package apt, file
apt-pkg/tagfile.cc) which results in non-aligned reads of funny
amounts.
"strace aptitude" says:
read(16, "des@debian.org>\nArchitecture: ar"..., 25624) = 25624
read(16, "\nSHA1: cca5d43ab22967baeb5638d5c"..., 25349) = 25349
read(16, " BiDi viewer - command-line tool"..., 25246) = 25246
read(16, "orola\'s 68HC11/12 targets\n The p"..., 25122) = 25122
read(16, "es, and the filesystem.\n .\n This"..., 24845) = 24845
read(16, "ersion: 1:2.2.17.20070822-5\nDepe"..., 25548) = 25548
read(16, " and provides\n several new widge"..., 24888) = 24888
read(16, "tra\nSection: misc\nInstalled-Size"..., 25692) = 25692
cos it's doing its own I/O buffering and using system calls directly
to read non-aligned blocks of funny sizes, presumably written by
someone who didn't know about the advantages of page-aligned reads of
page-sized amounts. If they'd just used stdio it would have done this
for them.
So the easy answer is speed up your I/O, the hard answer is to
reimplement the apt-pkg library's file-reading code to be less clever
and more intelligent, followed by execution profiling to find and
optimise other hot spots (like building the view).
That said, the lenny version of aptitude is better, since it doesn't
bother writing out databases that it has not changed
M
Reply to: