On Mon, Jan 06, 2003 at 06:02:58AM -0800, Alexander Hvostov wrote:
> Perhaps it's high time dpkg received some serious optimization. The way
> in which the package control info is stored and processed is horribly
> inefficient.
Yes. (I run Woody on a 486DX2/66, 16MB RAM. dpkg crawls.)
> Here's some suggestions:
>
> - Rather than storing data for each and every package in the single file
> '/var/lib/dpkg/{status,available}', store each package's data in its own
> file '/var/lib/dpkg/{status,available}/foo'.
IMHO that would be *less* efficient. Ever noticed how long it takes to
ls /var/lib/dpkg/info? Ext2/3 does not cope well with lots of small
files in a big directory.
> - Store frequently accessed control fields from status/available in a
> cache (Berkeley db or some such) for fast access. The cache is, of
> course, rebuilt if deleted or /var/lib/dpkg/{status,available}/* changes
> (as happens with 'dselect update').
I think that is a good idea.
> - Store a database of files on the filesystem and the packages they
> belong to in a cache, like above.
I believe dlocate does something like this.
Marius Gedminas
--
CBQ is merely the oldest kid on the block - yet it is by far the least useful
qdisc and also the most complex one. I advise *against* using it. This may come
as something of a shock to many who fell for the 'sendmail effect', which
learns us that any complex technology which doesn't come with documentation
must be the best available.
-- Linux Advanced Routing HOWTO
Attachment:
pgplPmWERKrHQ.pgp
Description: PGP signature