Re: dpkg --smallmem has a larger footprint than --largemem

["Zack Weinberg" <zackw@stanford.edu>]

Ian Jackson writes:
>Ben Collins writes ("Re: dpkg --smallmem has a larger footprint than --largemem"):
> > Simply calling stat() on all those files is a real performance jerk.
>
> This is because the .../info directory is so large - because it
> contains at least one file (and usually more) per package.  This is
> fine for the maintainer scripts, only a few of which are touched for
> each thing dpkg does.  But it's not so good for the .list files.  It
> used to be OK when we only had a few '00 packages :-).

I tested this and it does _not_ appear to be a bottleneck.  With a hot
disk cache:

$ time grep -F /usr/bin/telnet.netkit /var/lib/dpkg/info/*.list
/var/lib/dpkg/info/telnet.list:/usr/bin/telnet.netkit
0:00.03 - 0.01u, 0.02s, 100% - 128/26

$ time dpkg -S /usr/bin/telnet.netkit
telnet: /usr/bin/telnet.netkit
0:00.45 - 0.44u, 0.02s, 100% - 148/1833

These two commands do effectively the same sequence of disk accesses
(open+fstat+read each .list file).  And they spend the same amount of
time in the kernel.  dpkg -S is a lot slower, but it's all user time.
It also has a lot more minor page faults (the number after the slash)
which means it's using a lot more memory.

I have 425 .list files.

zw